On 11.04.2016 21:44, Tanu Kaskinen wrote:
On Sat, 2016-04-09 at 11:31 +0200, Georg Chini wrote:
On 08.04.2016 20:23, Georg Chini wrote:
On 08.04.2016 18:01, Tanu Kaskinen wrote:
On Wed, 2016-04-06 at 21:17 +0200, Georg Chini wrote:
On 06.04.2016 15:55, Tanu Kaskinen wrote:
On Tue, 2016-04-05 at 21:54 +0200, Georg Chini wrote:
On 05.04.2016 17:42, Tanu Kaskinen wrote:
Anyway, even if you think it is wrong I am still measuring
the
correct
end-to-end latency with my code, so something I am doing
must be
right ...
From what I can tell, that's a coincidence.
No, it definitely isn't. If you accept the precondition, that
samples
not simply vanish from the latency reports, it's physics.
I would tend to agree that I have overlooked something, if the
"extra
delay" would be the same every time and if I could not write down
the math for it.
But it isn't completely constant (just in the same range) and I can
write down the math and it matches my measurements. So I am
fairly sure that I am right. Did you have a look at my document?
Let me try to explain again:
Assume your first block of data has 10ms length. This means that
your first sample has 10ms delay.
What, where does that 10 ms delay come from for the first sample? Do
you mean that if pulseaudio wrote 100 ms in the ring buffer before
snd_pcm_start(), there would be 100 ms latency for the first sample?
yes, surely. To write 100ms of audio you must have them first. I think
you would agree, that the last sample you write has a delay of 0ms
because it is the current sample. The first sample however is 100ms
older, so consequently, since samples are isochronous, the first sample
must have 100ms delay, unless you say that the last sample you
wrote has a delay of -100ms.
It's just a matter of origin.
The delay for the first sample is zero plus the delay between the ring
buffer and the DAC.
No, the first sample has the delay of the block length, see above.
Again, it is a matter of origin, but the correct origin is the time when
the first sample is produced and not when it is written into the buffer.
If you now call snd_pcm_start()
and it takes another 10 ms before that sample is played, it then has
20 ms delay. Because the samples are isochronous, all following
samples will also be delayed by 20 ms.
No, there's only a 10 ms minimum delay imposed by the pipeline between
the ring buffer and the DAC. The rest of the delay depends on the ring
buffer fill level at any given moment. PulseAudio will wait until it's
empty before writing the next chunk, so the first sample of the next
chunk will have 10 ms delay when written to the ring buffer
(oversimplified a bit, since pulseaudio doesn't actually wait until the
ring buffer is empty, there are some safety margins to avoid
underruns).
This has absolutely nothing to do with buffers but only with the passing
of time. Leave your buffer-centered thinking and think in terms of time
instead. Samples have the same distance in time, where ever they are
buffered, so once you have a delay, you cannot remove it without
dropping samples.
Nothing can remove this additional delay unless you drop samples and
accept a gap in the audio.
The 10 ms minimum delay between the ring buffer and the DAC is not
removable in any case. Dropping samples doesn't help.
Whatever latency the ring buffer contributes can be removed by waiting
until the ring buffer is less full, no gaps in the audio.
See above, buffers are completely irrelevant.
Now, if the driver does not hide samples (like it does in your
invisible buffer example), you can use my method t determine the
delay between snd_pcm_start() and the start of playback (within the
bounds of the granularity of the delay reporting).
Even in your invisible buffer example my method would give a more
accurate value than the current code does, although it would assume
that the sample has been played as soon as it is no longer reported.
In my invisible buffer example the invisible part's size has no effect
on the values that your method generates. Your method adds the size of
the "send buffer" (the middle part of my buffer diagram) to the
reported delays, so if we change my example so that the invisible
part's length is zero, your method produces 3 ms too large delay
values, while the unadjusted delay reports would be accurate. If the
invisible part's length was 3 ms, your method would accidentally
produce accurate results.
Think again. If the invisible buffer part was not there, my code
would report exactly the correct value.
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
