4 ms·

No. Both JACK and CoreAudio ensures that there's no buffering between audio nodes in different processes either. Again, cc @PaulDavisThe1st

nyanpasu64 4y ago
Sadly, most audio APIs are not "half-decent" at zero-latency inter-app routing and minimal mixing/output latency (for a particularly bad example, see https://superpowered.com/androidaudiopathlatency https://superpowered.com/androidaudiopathlatency). JACK on Linux supported this but few apps supported it, ALSA and PulseAudio loopback devices don't have it to my knowledge, and PipeWire is the first chance at bringing mainstream non-musician apps to this promised land (but only JACK and PipeWire apps, and Pulse and ALSA apps still have added latency). Additionally, conventional hardware input/output requires at least two periods of buffering for a stable duplex session (mic input and speaker playback simultaneously). On startup, you fill the output buffer with 2 periods of silence. Every period (when input buffer grows and output buffer shrinks by 1 period), you take 1 period of input audio, feed it through the audio graph (which can take up to 1 period otherwise your speakers run out of audio to play and stutter), then write 1 period of output audio to the speakers. Smaller periods (lower sample/frame count, lower duration in ms) reduce latency, but increase the risk of stutter if your system can't schedule and run all audio apps in 1 period of time.
- aaaaaaaaaaab 4y ago
  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

Sadly, most audio APIs are not "half-decent" at zero-latency inter-app routing and minimal mixing/output latency (for a particularly bad example, see https://superpowered.com/androidaudiopathlatency https://superpowered.com/androidaudiopathlatency). JACK on Linux supported this but few apps supported it, ALSA and PulseAudio loopback devices don't have it to my knowledge, and PipeWire is the first chance at bringing mainstream non-musician apps to this promised land (but only JACK and PipeWire apps, and Pulse and ALSA apps still have added latency). Additionally, conventional hardware input/output requires at least two periods of buffering for a stable duplex session (mic input and speaker playback simultaneously). On startup, you fill the output buffer with 2 periods of silence. Every period (when input buffer grows and output buffer shrinks by 1 period), you take 1 period of input audio, feed it through the audio graph (which can take up to 1 period otherwise your speakers run out of audio to play and stutter), then write 1 period of output audio to the speakers. Smaller periods (lower sample/frame count, lower duration in ms) reduce latency, but increase the risk of stutter if your system can't schedule and run all audio apps in 1 period of time.

aaaaaaaaaaab 4y ago
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.