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

[Georg Chini]

On 28.03.2016 16:16, Pierre-Louis Bossart wrote:
> On 3/22/16 4:11 AM, Georg Chini wrote:
>> Hi,
>>
>> when a sink is started, there is some delay before the first sample is
>> really played.
>> This delay is a constant part of the sink latency that will be always
>> present, so the
>> minimum sink latency cannot go below that start delay.
>> Would it be acceptable to adjust the latency range for the device after
>> each unsuspend
>> to reflect that?
>> USB devices (those I have access to) for example have a startup delay in
>> the range of
>> 10ms, but have a latency range that starts at 0.5ms which does not make
>> a lot of sense
>> in my opinion.
>> The startup delay is not constant, so the minimum possible latency would
>> vary.
>>
>> On the source side the startup delay is not relevant since it does not
>> delay the signal.
>
> 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.

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

> The ALSA driver tells you however when it started pushing samples out 
> after the .prepare step, the status.trigger_time value tells you what 
> your starting point should be. All the smoothers should start from 
> this value, not from the time you started pushing the samples in the sink.

The observable latency is the time that it takes from pushing a sample 
into the sink
to the moment it reaches the analog output. This is the same time for 
the first sample
as for all following samples, see above.
For the smoother itself you can use any arbitrary chosen time after the 
trigger_time
as starting point, you only have to remember the number of frames that 
have already
been played at that time. I experimented with using the start time 
supplied by the
driver and could not see a significant advantage over the first approach.

> The latency specified by PulseAudio is only related to the continuous 
> latency - the total buffering. There is no need to take the startup 
> delay into account as long as you use the trigger_time as your t0.
> Some devices don't report trigger_time accurately but in the case of 
> USB there were patches to fix this last year, look for the subject
> "ALSA: usb: update trigger timestamp on first non-zero URB submitted"
The trigger_time tells you, when the first audio is submitted to the USB 
bus, but not
when it really reaches the speakers. There is all that USB processing in 
between.