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.
