23 ms·

>On a computer, the audio must be buffered whenever transferred between components Not true. Any half-decent audio API will drive the whole audio graph from th

>On a computer, the audio must be buffered whenever transferred between components Not true. Any half-decent audio API will drive the whole audio graph from the hardware I/O callback, so there’s only a single buffer, usually of length 256-512 samples. cc @PaulDavisThe1st

black_knight 4y ago
How does that work? Sure, the buffers are in the hardware, but there still needs to be buffering between each pair of components? Say between two different effect plugins.
- NavinF 4y ago
  When people talk about audio buffers they’re talking about something that’s filled and drained from RAM when an interrupt fires every 1ms, not the data that’s processed every few nanoseconds as the CPU moves on from running one filter/plugin to the next. The latter doesn’t even leave the CPU cache.
- aaaaaaaaaaab 4y ago
  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.

black_knight 4y ago

How does that work? Sure, the buffers are in the hardware, but there still needs to be buffering between each pair of components? Say between two different effect plugins.

NavinF 4y ago
When people talk about audio buffers they’re talking about something that’s filled and drained from RAM when an interrupt fires every 1ms, not the data that’s processed every few nanoseconds as the CPU moves on from running one filter/plugin to the next. The latter doesn’t even leave the CPU cache.
aaaaaaaaaaab 4y ago
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.