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

[Georg Chini]

On 29.03.2016 05:56, Georg Chini wrote:
> On 29.03.2016 02:13, Pierre-Louis Bossart wrote:
>> On 3/28/16 12:38 PM, Georg Chini wrote:
>>> On 28.03.2016 17:18, Georg Chini wrote:
>>>> On 28.03.2016 16:16, Pierre-Louis Bossart wrote:
>>>>> On 3/22/16 4:11 AM, Georg Chini wrote:
>>>>>> Hi,
>>>>>>
>>>>> Ups, looks like I misread your sentence above. You are right, in
>>> software you can't
>>> see the output. But what you can see is the time between dispatching 
>>> the
>>> audio
>>> to the USB bus and the time when the bus reports back that the audio 
>>> was
>>> played.
>>>
>>> I am not sure if I read the code right, I don't know anything about 
>>> USB,
>>> but if the
>>> URB's you are submitting to the bus in the prepare step are handled in
>>> chronological
>>> order, it means that
>>> a) you have to wait for the next URB to retire before you can send any
>>> real audio
>>> b) after you submitted the first audio, it is at the end of the queue
>>> and all the other
>>> URB's containing silence will be processed first.
>>
>> 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.
>>
> 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.

OK, I thought about it another time and I believe I figured out what the 
problem is.

(Sometimes I feel like I am talking Chinese to you - I seem not to be 
able to express
myself in a way that others can understand, sorry for that. I'll try my 
best now.
If we would sit in one room it would probably be sorted out in half an 
hour.)

The starting point is the observation, that with module-loopback and an 
USB sink
the real end-to-end latency is about 10ms longer than configured. This 
cannot be
observed with a HDA sink. Let's go through the sequence of events when
module-loopback is started:

1) The module sets up a buffer and fills it with silence up to the 
configured loopback latency.
Sink and source are configured to 1/3 of the loopback latency. In this 
example, we will use
30ms as loopback latency, so that sink and source are configured to 10ms.

2) Source and sink are started. For simplicity we assume that the source 
starts delivering
samples immediately.

3) As long as sink_input_pop() has not been called, module-loopback 
drops the audio
coming in from the source.

4) On the alsa side, the preparation has been done. Again, to simplify 
we assume 2 URB's
with 5ms each have been set up and submitted to the USB bus. The first 
URB starts
playing silence to the speakers now.

5) The pulseaudio sink code takes the first 10ms of audio out of the 
loopback buffer,
writes it to the alsa buffer and calls snd_pcm_start().

6) Now sink_input_pop() is called, and that is where things go wrong, 
because the
audio from the source is buffered from now on.

7) On the alsa side nothing has happened yet. The reported delay is what 
is in the alsa
buffer - 10ms. Alsa has to wait for the first URB to expire before any 
sample can be
submitted to the bus.

8) Now the first URB has retired and can be filled with audio. After the 
URB is submitted to
the bus, the alsa delay is NOT updated and still shows 10ms. The second 
URB starts playing
silence for 5ms. Because the buffer seems filled to the correct level, 
the pulseaudio sink
code will wait until the fill level gets lower.

9) The second URB has retired, is filled with audio and submitted to the 
bus. Still the
delay is NOT updated, but from now on, it is correct, since a sample 
that would now be
submitted to the alsa buffer would take 10 ms to the speakers. The first 
real audio starts
playing.

10) Meanwhile the source has been producing samples that have been queued in
the loopback buffer and that make up the extra latency I have been 
observing. In
this example it would be 5ms from the second URB plus the time that was left
from the first URB when snd_pcm_start() was called.

11) The first URB-full of audio has been played and the URB retires. Now 
the alsa
delay is adjusted to reflect that the first 5ms have been played and the 
audio flow
is completely set up.

If the first sink_input_pop() would be called at this point, everything 
would be fine.
So the problem seems to be that sink_input_pop() is called too early.

I hope I was able to find the right words this time ...