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

[Tanu Kaskinen]

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?

The delay for the first sample is zero plus the delay between the ring
buffer and the DAC.

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

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

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

-- 
Tanu