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.
