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

[Tanu Kaskinen]

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

-- 
Tanu