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

[Georg Chini]

On 19.04.2016 12:57, Tanu Kaskinen wrote:
> On Sun, 2016-04-17 at 13:15 +0200, Georg Chini wrote:
>> Hi Tanu,
>>
>> finally I figured it out where I went wrong. We are both right to some
>> extent,
>> but (what is the important bit) you are right in so far, that the
>> startup delay
>> should not be included in the latency reports. So sorry for the second mail
>> worm I have produced. As already mentioned in a previous mail we probably
>> could have sorted it out in half an hour if we had talked about it
>> instead of
>> writing mails.
>> Let me explain what I mean:
>>
>> First, please forget about pulseaudio for a moment, because we now talk
>> about a basic property of a stream which has nothing to do with the medium
>> that transports the stream.
>> Consider a source (just something producing samples, not the pulseaudio
>> source) and a corresponding sink. These are the preconditions:
>> - Source and sink share the same sampling rate, the time distance between
>> samples is dt = 1 / f.
>> - No samples will be dropped/inserted and no sample rate changes occur
>>
>> At time t=0, the source produces the first sample.
>> There is some delay T, after which the first sample reaches the sink
>> and is played.
>> So the delay of the first sample is T.
>> Meanwhile, the source continues to produce samples.
>> At time t=dt the source produces the second sample.
>> Because source and sink share the same sampling rate, on the sink
>> side the second sample must be played at T + dt.
>> So the second sample has delay T + dt - dt = T.
>> At time t=2dt the source produces the next sample. On the sink side,
>> for the same reason as above, the third sample will be played at T + 2dt.
>> Again the delay is T.
>> And so on. How could this ever change without breaking the continuity
>> of the stream?
>>
>> So you see, that the delay of the stream is set by the first sample and you
>> cannot change it, unless you use one of the stream manipulations I excluded
>> in the preconditions. This is where I am right.
>>
>> On the other hand, in pulseaudio the number of samples in the sink is kept
>> constant until the sink really starts playing. This means, that the
>> delay of the
>> top sample in the buffer will get smaller relative to "now" (though not
>> relative
>> to the start of the first stream) until the startup delay has passed.
>> Therefore
>> streams that are started after the startup delay has passed, will see only
>> the dynamic delay.
>> This is where you are right and why the startup delay should be ignored
>> in the latency reports. But still, from the perspective of the first stream,
>> this part is relevant as explained above and module-loopback has to get
>> rid of the excess latency (which it does).
>>
>> I will change the code and the documentation accordingly which is pretty
>> simple. Again, sorry for being so slow to pick up the drift twice. I have to
>> admit that I am quite embarrassed. Thanks for your patience.
> Sorry for not being responsive lately - luckily getting you to
> understand turned out to be the kind of problem that solves itself when
> ignored long enough :)
>
> Your latency calculation adjustments were intended to also fix the
> error in the reports that occur in your measurements with USB also
> after things have stabilized, which are unrelated to the startup delay.
> Now that you "saw the light", have you given up on correcting those
> errors? (I hope you have, since I don't think there's any way to
> correct them.)
>
Well, once you start doing things correctly, some errors vanish ...
What remains is a constant latency offset of 15 ms that you have
to set manually, which is large but acceptable.
All the calculations around have however not changed, it's just
"ignore that part " instead of "include that part" at one point.