Re: I'm confused about latency
Alexandre BIQUE <[email protected]> Fri, 5 Apr 2019 10:36:02 +0200
| Newsgroups | gmane.comp.audio.jackit |
|---|---|
| Message-ID | <[email protected]> |
On 4/5/19 2:56 AM, Thomas Brand wrote: > On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote: >> On 4/4/19 8:41 PM, Thomas Brand wrote: >> >>> Did I understand your use case correctly: you want to be able to tell >>> (from a client's perspective) how long it will take from *now* (this >>> cycle) until the start of the buffer is played out (eg. the first sample >>> of buffer hits the DAC) ~ ?? >> >> Yes, something equivalent to snd_pcm_htimestamp(). >> >> > This page has a nice diagram: > http://manual.ardour.org/synchronization/latency-and-latency-compensation/ > I don't know how accurate the delay from data leaving jack until it is > heard at the analog output can be known. It's around 2.5 ms. But is it the > same for every ALSA device and driver? jack_iodelay can measure round-trip > latency and you could adjust your system based on jack_iodely output. 2.5 ms is quite a lot, and should be somehow reported by device API (ALSA, ASIO, CoreAudio, ...): - the driver should have a rough idea of how much hardware latency is introduced by the audio interface - the OS should have a rough idea of how much scheduling/internals latency is introduced Even if those values are not correct if they can reduce the "error" it is worth it right? I'm skeptical that people want to put a feedback cable into their audio interface and measure exactly how much latency is introduced, and then configure their tools with some mystic latency compensation. I really think that if we can get some values from the OS which minimize the error that would be better. Cheers, Alexandre