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

[Georg Chini]

On 22.03.2016 12:20, Tanu Kaskinen wrote:
> On Tue, 2016-03-22 at 10:11 +0100, 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.
> I don't understand why the startup delay would limit the minimum
> latency once the stream is flowing. Imagine a sound card that is
> powered by a nuclear power plant. I don't know how long it takes to
> start a nuclear power plant, but let's say it takes a couple of days.
> Now the sound card startup delay is a couple of days, but there's no
> reason that the audio latency has to be a couple of days once the power
> plant is running. Where would all that audio be buffered anyway?
>
Hi Tanu,

you are wrong. I expected a reply like this. The sink is started up at 
the moment
when you write the first data to the buffer, so all following data can 
only be played
when the previous data has been handled. This means, that the startup 
delay will
persist forever unless you are dropping samples (which you would have to 
do in
your example above but which is not done in pulseaudio).
Actually you can see that startup delay when you use an oscilloscope because
the real latency is off by that amount.