5 ms·

Yeah, Android and realtime audio shouldn't occur in the same sentence, but that's due to their business model ¯\_(ツ)_/¯ I was explicitly mentioning JACK and Co

Yeah, Android and realtime audio shouldn't occur in the same sentence, but that's due to their business model ¯\_(ツ)_/¯ I was explicitly mentioning JACK and CoreAudio, because the discussion was about professional audio tools. >Additionally, conventional hardware input/output requires at least two periods of buffering for a stable duplex session This is not true if both the input and output are coming from the same device. In that case you can serve both input and output within the same IO callback, thus the playthrough latency will be only a single period. Multi-device playthrough is more complicated, as you'd need asynchronous sample-rate conversion due to different hardware clocks (i.e. clock drift), which inherently increases latency.

nyanpasu64 4y ago
> In that case you can serve both input and output within the same IO callback, thus the playthrough latency will be only a single period. By playthrough latency, do you mean having the output play the same audio being captured from the input/mic? One period of loopback/playthrough latency is only possible if you can instantaneously copy data from the input to output buffers (for example by using the same hardware buffer for both?). In practice, PipeWire and JACK2 both introduce 2 periods (in PipeWire, quantums) of buffering latency, which I've discussed in my blog (https://nyanpasu64.gitlab.io/blog/low-latency-audio-output-duplex-alsa/ https://nyanpasu64.gitlab.io/blog/low-latency-audio-output-d...), or you can confirm by reading their source code.
- aaaaaaaaaaab 4y ago
  Hmmmm… actually you’re right! I was thinking that there’s going to be a single I/O interval between the end of the input buffer and the start of the output buffer, but now I realize that this means 2 x I/O interval latency between the input and output streams.

nyanpasu64 4y ago

> In that case you can serve both input and output within the same IO callback, thus the playthrough latency will be only a single period. By playthrough latency, do you mean having the output play the same audio being captured from the input/mic? One period of loopback/playthrough latency is only possible if you can instantaneously copy data from the input to output buffers (for example by using the same hardware buffer for both?). In practice, PipeWire and JACK2 both introduce 2 periods (in PipeWire, quantums) of buffering latency, which I've discussed in my blog (https://nyanpasu64.gitlab.io/blog/low-latency-audio-output-duplex-alsa/ https://nyanpasu64.gitlab.io/blog/low-latency-audio-output-d...), or you can confirm by reading their source code.

aaaaaaaaaaab 4y ago
Hmmmm… actually you’re right! I was thinking that there’s going to be a single I/O interval between the end of the input buffer and the start of the output buffer, but now I realize that this means 2 x I/O interval latency between the input and output streams.