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

[Pierre-Louis Bossart]

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,
>>>>
>>>
>>> Sorry I missed this thread last week.
>>> At the risk of being pedantic, maybe you should consider two
>>> different concepts.
>>> - cold latency: the time it takes for the audio device to render the
>>> first sample when first opened
>>> - continuous latency: the time it takes to hear a sample after it's
>>> written to the ring buffer.
>>>
>>
>> Yes, but it looks like the alsa USB driver assumes that a sample can
>> be heard immediately
>> after it left the buffer, which is not true. So there is some
>> additional continuous latency
>> that is not reported. This is visible as a "startup delay" - the time
>> between the moment
>> the first sample is written to the buffer and the moment when it is
>> reported that the
>> first chunk of audio has been played.
>
> More correctly the time between snd_pcm_start() and the moment when the
> first chunk
> has been played minus the chunk time, since the buffer is filled before
> snd_pcm_start()
> is called.
>
>>
>>> The cold latency is mostly what happens in the .prepare step at the
>>> driver level. It's very hard to estimate by software since you can't
>>> observe the analog output. It can also vary depending on platform
>>> states.
>>
>> Well, I can observe the analog output. In my setup I have an
>> oscilloscope connected
>> to input and output of the loopback, that is why I detected the
>> difference between
>> configured and real latency at all.
> 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.