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

[Georg Chini]

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).
>
>> 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?
>

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?

> 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
>
>