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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
