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
