[pulseaudio-discuss] Question regarding latencies reported by alsa-source and alsa-sink

[Tanu Kaskinen]

On Sun, 2016-01-17 at 19:07 +0100, Georg Chini wrote:
> On 17.01.2016 17:17, Georg Chini wrote:
> > On 17.01.2016 14:40, Tanu Kaskinen wrote:
> > > On Sat, 2016-01-16 at 23:22 +0100, Georg Chini wrote:
> > > > Hello,
> > > > 
> > > > I have been working on a new version of module-loopback for quite a
> > > > while now.
> > > > I am also replacing the smoother in alsa-source and alsa-sink to 
> > > > achieve
> > > > more
> > > > precise latency reports.
> > > > Now I hit a problem, were I am not sure how to solve it. The 
> > > > get_latency
> > > > calls
> > > > of alsa-sink and alsa-source truncate the latency to 0 when it becomes
> > > > negative.
> > > > Would it be possible to let the calls return negative values?
> > > > Due to the error in the initial conditions those values still make 
> > > > sense
> > > > and clipping
> > > > them causes massive problems for the rate controller of 
> > > > module-loopback.
> > > > 
> > > > If it is not possible to let the calls return negative values, do you
> > > > have any other
> > > > idea how to work around the problem?
> > > Reporting negative latency doesn't make sense, since it implies time
> > > travel. Where do those negative latency values come from?
> > 
> > I know it requires time travel ...
> > Negative values are due to the fact that you have to assume
> > some point in time as the starting point. In my new code this
> > is done directly while the smoother does the same more indirectly
> > (and also delivers negative values).
> > At that starting point, a certain number of samples have already been
> > played or recorded. If that number has an error, you can get negative
> > latency values (which are in the order of a few hundred usec).

Ok. It's not necessary to assume a starting time, though, unless you
use the system clock in the latency reports. The current implementation
uses the system clock, and apparenty you use it too in your new code.

> > > Filtering out obviously incorrect values seems appropriate for most use
> > > cases. If you really need access to "unfiltered" values, maybe
> > > pa_sink_get_latency() could have an "allow_negative" parameter or
> > > something similar.
> > 
> > Wouldn't that require changes also on the client side? Or do clients 
> > never
> > call this function directly?

Clients can't call pa_sink_get_latency() directly. The pa_sink_*
functions aren't included in the client library. Even if a client would
be misguided enough to link to the server's internal library, it
wouldn't work, because the client runs in a different process.

> > Would it perhaps make sense to add a
> > pa_sink_get_unfiltered_latency() call?
> > 
> 
> Meanwhile I implemented those calls (or rather their _within_thread_ 
> variants)
> for alsa sink and source.
> If a sink or source does not have it (like bluetooth), the "normal" latency
> is returned.
> Would you be OK with that approach?

I suggested a boolean flag, because I expect that to result in less
code duplication. If my expectation is wrong, or there's some problem
with using the flag, then adding separate functions is fine.

-- 
Tanu