3 ms·

Let’s say you have an audio graph like this in your DAW: synth → reverb → output Every 5.33ms the OS audio system (CoreAudio, JACK, etc.) calls your DAW to pr

Let’s say you have an audio graph like this in your DAW: synth → reverb → output Every 5.33ms the OS audio system (CoreAudio, JACK, etc.) calls your DAW to produce 256 samples of audio. The DAW looks at the audio graph and asks the plugin connected to the output, the reverb, to produce 256 samples of audio. The reverb calls the next plugin, the synth, to produce 256 samples of audio, then applies the reverb effect on it, then returns it to the DAW, which returns it to the OS, which writes it to the audio hardware’s buffer. This all happens within the same 5.33ms callback. You can have as many plugins as you like, there’s no additional latency (unless the plugin explicitly adds buffering).

black_knight 4y ago
Ah, I see. So, within a given process (such as a DAW) you can bundle stuff together, as long as the combination of everything is fast enough to make the deadline. But different processes communicating over, say, JACK, still have buffering between them.
- aaaaaaaaaaab 4y ago
  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.

black_knight 4y ago

Ah, I see. So, within a given process (such as a DAW) you can bundle stuff together, as long as the combination of everything is fast enough to make the deadline. But different processes communicating over, say, JACK, still have buffering between them.

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