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). > 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? Would it perhaps make sense to add a pa_sink_get_unfiltered_latency() call? BTW, the problem is rather on the source side. Due to the way the latency snapshots are obtained in module-loopback, the source always reports near zero latency. > > -- > Tanu
