Audio setup
Interfaces, drivers, sample rate, buffer size, and latency on each OS.
Everything on this page lives in one dialog: View → Audio Settings…, also reachable from the gear icon in the main toolbar. Get the driver, sample rate, and buffer size right once and most latency and crackle problems never appear. Shortcuts follow the OpenStudio default keyboard profile.
In the September 29 development checkout (52cbd7c plus uncommitted changes), an audio-device interruption stops and finalizes the current take. Check the input device and channels before starting another take; recording does not silently continue through a replacement device. Sustained microphone and platform qualification remain separate from this safeguard.
Interfaces and drivers
OpenStudio lists the audio devices available through the selected driver backend; compatibility depends on the interface and driver. The number of inputs you can pick on a track header comes straight from the interface's channel count. What matters more than the interface is the driver path you choose in Audio System.
| Windows driver type | What it is |
|---|---|
| ASIO | Low-latency professional audio drivers, supplied by the interface vendor |
| WASAPI | Windows Audio Session API, built into Windows 10 and later |
| DirectSound | Legacy Windows audio, higher latency |
ASIO is an optional dependency: OpenStudio launches without it and falls back to the system paths, so a missing vendor driver never stops the app from starting.
For USB or webcam microphones, select Windows WASAPI or macOS CoreAudio, choose the microphone as Input Device, and select its mono channel on an armed audio track. Grant operating-system microphone permission. A vendor ASIO driver exposes that interface's inputs; an unrelated USB microphone does not become an Audient ASIO input. Mixing a WASAPI input with an ASIO output is not supported by selecting one backend. macOS aggregate devices are configured in Audio MIDI Setup. Verify a real recording with the chosen device pair.
Choosing the settings
Reviewed October 24, 2026 against app commit 1b5ba4b7. Audio Settings refreshes device options and selects a new device's reported defaults. Inactive ASIO drivers report rates, preferred buffer and supported sizes without starting an audio stream; 8/16-sample options appear when reported. Unavailable inspection shows an error. Apply verifies rate-dependent constraints and refreshes accepted values without closing; OK closes when the requested values are accepted; Cancel discards the draft. On the right of the File/Edit menu row, a compact rate/buffer display describes the running device. These changes are unreleased; hardware and platform qualification remains incomplete.
In the October 23 development checkout, Active audio shows the running rate and buffer while Pending shows your unapplied choices. For example, choosing 64 samples can leave Active audio at 44,100 Hz / 8 samples until you choose Apply or OK. A supported rate or buffer edit stays pending during discovery on the same device. Check the active values after applying, then test the complete project. If no device is open, the dialog reports that instead of showing zero-valued active settings. This does not qualify a particular buffer as crackle-free.
A failed query leaves your chosen rate and buffer visible as pending. Use Retry or change the selection before applying. If the native driver opens different values from those requested, OpenStudio reports the mismatch and attempts to restore the previous setup; the running-device display reports the actual recovery state. The dialog also handles an apply result that reports success with different accepted values: OK stays open, a message shows requested versus accepted values, and the controls show the active settings for review. For example, requesting 16 samples and receiving 8 is made explicit. This feedback does not force driver support or establish that an Audient or other ASIO hardware issue is fixed; verify your interface before recording.
- Open View → Audio Settings….
- Pick an Audio System. On Windows choose ASIO where you can.
- With ASIO, pick the ASIO Driver. With WASAPI or DirectSound, pick an Input Device and an Output Device separately.
- Choose a Sample Rate. 44100 Hz and 48000 Hz are standard; use whatever your interface runs at natively.
- Set a Buffer Size. 256 or 512 samples is the right starting point.
- Click Apply to activate the settings.
The audio device sample rate controls recording and playback. Imported files can keep their original rate; playback converts them in real time using linear interpolation. Offline rendering can target a different rate from the render dialog.
Buffer size and latency
The buffer is how much audio the engine processes per callback. A smaller buffer means the sound reaches your ears sooner and the CPU has less time to do the work; a larger buffer is safer and later. Monitoring latency also depends on sample rate, the driver and interface, and latency introduced by plugins. Choose and test the buffer before recording.
| Buffer | Use it when |
|---|---|
| 128 | Lowest monitoring latency; only if the machine keeps up without crackle |
| 256 | The starting point for recording sessions |
| 512 | A safe starting point on a busier project, or the first step up when 256 crackles |
| 1024 | Sessions with many tracks and plugins where monitoring latency does not matter |
The pattern that works: record at 128 or 256, then raise the buffer to 512 or 1024 once the tracking is done and the plugin count grows. Freezing heavy tracks (right-click → Freeze Track) is the other lever when a small buffer starts to crackle.
Input monitoring
Arm a track and toggle Monitor on its header to hear the live input. The signal passes through the track's full chain, input FX and track FX included, before it reaches the output, which is what lets you hear a NAM Rack tone or a compressor while you play. Monitoring latency also includes driver buffering, interface conversion, and any plugin latency.
Set the buffer before you record, not after. Leave headroom when setting input levels and aim for peaks around −12 to −6 dB on the track meter.
macOS microphone permission
macOS gates every audio input, including USB and Thunderbolt interfaces, behind the Microphone privacy permission. If access was denied, the device still appears in Audio Settings but every recorded sample is silent.
- Quit OpenStudio.
- Open System Settings → Privacy & Security → Microphone and enable OpenStudio.
- Reopen OpenStudio, select the input device again, arm a track, and check the input meter.
If OpenStudio is missing from that list or the stored decision seems stuck, reset the permission for the installed bundle only. Adjust the path if the app is not in Applications, then relaunch and click Allow when asked.
bundle_id="$(defaults read /Applications/OpenStudio.app/Contents/Info CFBundleIdentifier)"
tccutil reset Microphone "$bundle_id"A bare tccutil reset Microphone clears the permission for every application on the machine. Keep the bundle identifier unless that is what you want.
Fixing latency and crackle
Latency and crackle pull in opposite directions on the same control, so treat them together. Too late to play against: go smaller. Pops and clicks: go bigger.
| Symptom | Try, in order |
|---|---|
| Noticeable delay between playing and hearing it | Switch to ASIO on Windows; lower the buffer to 128 or 256; close other audio apps competing for the device; if that crackles, step the buffer back up until it is stable |
| Pops, clicks, or crackle during playback or recording | Raise the buffer to 512 or 1024; freeze CPU-heavy tracks; reduce active plugins; close background apps; update the interface driver |
| Playback shows Playing but nothing is heard | Confirm the output device in Audio Settings; check the interface is on; check mute, solo, and master volume; on ASIO make sure no other app holds the driver exclusively |
The NAM Rack's own click and noise behaviour at small buffers is still listed as a release audition item upstream, so if the rack crackles at 128 where a plain track does not, that is worth reporting on the issue tracker rather than a setting to fight. More symptoms are indexed in Troubleshooting.
Signal flow
Knowing where in the chain each stage sits explains most surprises: why an input EQ ignores fader automation, why a post-fader send drops with the fader, why the master FX chain sees everything.
Audio input -> Input FX -> Track FX -> pre-fader send tap
|
Track fader and pan
|
post-fader send tap
|
Track output / routed bus
|
Master FX -> Master output- Input FX run before the fader, so fader automation does not affect them.
- Track insert FX run before the channel fader.
- Sends are pre-fader (independent of the fader) or post-fader (follow it), per send.
- The master bus receives the tracks and buses routed to it.
Sends, buses, and the routing matrix are covered in Mixing & routing.