[pulseaudio-discuss] alsa sink latency - how to account for startup delay

[Georg Chini]

On 29.03.2016 21:15, Georg Chini wrote:
> On 29.03.2016 20:59, Raymond Yau wrote:
>>
>>
>> >>
>> >> The USB driver will submit N silence URBs on startup in the 
>> prepare and you will have to wait for those URBs to retire before the 
>> samples are queued. There is very little 'USB processing'. If you 
>> want to reduce this delay you have to use smaller periods, it'll 
>> decrease the size of the URBs. I guess it could be possible to change 
>> the URB size after the start but that's not implemented atm.
>> >>
>>
>> For loopback, the source capture the same amount of data while you 
>> wait for the retitement of those urbs
>>
>
> Yes, that is exactly the point.

Well, it wasn't the point - see my reply to Tanu's last mail on that topic.

>
>> > I don't want to shorten the latency. I only want the latency 
>> reported correctly. To me it still
>> > looks like the real latency of the driver is not what it reports, 
>> because the time that the
>> > audio spends in the URB's is not taken into account. What I am 
>> seeing is, that the real
>> > latency is around 10ms longer than expected.
>>
>> The total number of URBs for the endpoint is not allowed to exceed 
>> MAX_URBS (which the patch increases from 8 to 12).
>>
>> Do this match with your measurement
>>
>>
> How much audio does one URB hold? The time I measure is between 8 and 
> 9 ms and does not
> depend much on the configured sink latency as far as I can tell. (I 
> tried latencies between
> around 10ms and 2s). I did however not check the dependency in detail, 
> most observations
> are with sink latencies in the range of 10 - 20ms.
>
OK, I did a few more measurements and the numbers I have given above are 
not correct.
The actual difference in overall latency is 12ms.
When I run module-loopback with 40ms configured latency, I will see 
about 42ms with my
code that accounts for the delay and 54ms with the old code.
So if an URB holds 1ms of audio, this could match.

I think the remaining 2ms are hardware delays, they are slightly 
different for different
combinations of source/sink and by setting small latency offsets (HDA 
source: 0ms
HDA sink: 2.8ms, USB source: 1.0ms and USB sink: 1.8ms) I am at 40ms 
+/-0.5ms
for all combinations.