5 Apr
2019
5 Apr
'19
3:36 a.m.
On 4/5/19 2:56 AM, Thomas Brand wrote:
On Fri, April 5, 2019 00:28, Alexandre BIQUE wrote:
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
On 4/4/19 8:41 PM, Thomas Brand wrote:
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. 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().