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

[Georg Chini]

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. 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. Nothing can remove this
additional delay unless you drop samples and accept a gap 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.

Actually there is some more delay which can not be accounted for.
Even if you can determine the point in time when a sample is delivered
to the hardware, it still needs to be processed by the hardware and any
analog circuit that might be behind the DAC. Anything after the point
where the driver communicates to the hardware is out of reach. This
is why even with my code, still some small but constant latency offsets
remain.