[pulseaudio-discuss] Question regarding latencies reported by alsa-source and alsa-sink
tanuk at iki.fi
Tue Jan 19 03:38:30 PST 2016
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_
> 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.
More information about the pulseaudio-discuss