Audio Settings is where you connect AnalogDAW to your hardware and tune the balance between latency and stability. Open it from ☰ ▸ Audio Settings….
These are app/hardware settings (which device, how big the buffer). The recording quality (sample rate / bit depth) of each project is set separately in Session Settings.
The Core Audio toggle turns the audio engine on or off. It's normally on (green, "Enabled"). On macOS, enabling it confirms microphone permission so inputs are accessible. On iPhone and iPad, AnalogDAW enables it automatically after creating, opening, recovering, or relinking a session, so the built-in mic and active network/audio plug-ins are ready without another visit to Settings. Turn it off only if you want to release the audio device.
Core Audio being enabled does not by itself open the microphone. A No Input track with a receiver plug-in before Record Point uses the output/render path only; the input path is activated only for hardware input monitoring or recording.
Use Refresh Devices if you plug in hardware and it doesn't appear, then Apply.
The current system input and output (e.g. Built-in Microphone / Built-in Speaker, or a connected interface/headset) are shown for reference; iOS manages routing through the system.
The buffer size is the core trade-off in any DAW. AnalogDAW offers the sizes your selected interface reports as usable from this set: 64, 128, 256, 512, 1024, or 2048 samples.
Rule of thumb: use a small buffer (64–256) while recording so performers feel in time, and a larger buffer (512–1024) while mixing so you can run lots of plug-ins without dropouts.
AnalogDAW can spread busy mixes across your Mac or iPad's performance cores automatically — there's nothing to configure. Light sessions stay on a lower- overhead serial path; when a callback approaches its deadline, the worker pool engages for eligible track, bus, and aux DSP. This also applies to a session with only a few tracks when an aux effect, bus/master chain, or plug-in makes the callback expensive; light callbacks still avoid multicore synchronization overhead when it would cost more than it saves.
Parallel work is not limited to tracks: dependency-independent track channels, group buses, and aux/effect returns can share the pool. The master chain and order-sensitive summing stay serial. In internal synthetic testing a heavy 48-track render ran about 2.8× faster across the pool than on a single core; real-session results depend on routing and plug-in cost.
When the audio device exposes a Core Audio workgroup, AnalogDAW's render workers join it as real-time audio peers. Consecutive buffers reuse one short active worker burst instead of repeating setup hundreds of times per second; helpers leave and return to their lower-overhead parked state when that burst goes idle. If measured parallel rendering remains slower than the serial callback that requested help, AnalogDAW automatically retreats and cools down before retrying. When the workgroup is unavailable, playback uses the same deterministic mixer with normal system scheduling.
Background anticipative read-ahead is not enabled in the current build. Its first implementation could not reliably stay ahead of 32/64-sample callbacks, so prerecorded tracks currently use the synchronous multicore path too. This avoids silence/dropouts from a starved read-ahead ring while that scheduler is being redesigned and device-validated.
This only changes how fast the mix is computed, never what it sounds like: the output is bit-for-bit identical no matter how many cores are used, and an exported file is byte-for-byte the same every time — safe for mastering. It pairs naturally with a larger buffer for the most headroom while mixing.
A live readout of the round-trip latency (and the output portion) for your current buffer and device, in milliseconds. The transport's tracking safety pill shows a related monitoring-latency estimate — roughly the buffer time, plus any master Maximizer look-ahead you have enabled — rated with a green/orange/red light. Lower is better for recording.
A fine compensation control (±2048 samples) that nudges recorded audio earlier or later to line up perfectly with the rest of the session. Most setups need 0, but some interfaces report their latency slightly off; if your recordings land a hair early or late against the grid, adjust this and re-test. Use the reset button to return to 0.
Shows the sample rate the hardware is currently running at. AnalogDAW drives your interface to the project sample rate, which you set in Session Settings.
The project rate wins. AnalogDAW actively changes your interface's rate to match the session — it does not resample the session to fit the interface. That happens whenever you:
You may notice the audio drop out briefly while the interface re-clocks; some interfaces take a second or two to settle, and a few will change rate for every app using them. AnalogDAW never does this while you are recording or exporting — a rate change requested then is held back and applied the next time the transport is safely stopped, so a take can't be interrupted mid-render.
If the interface can't run the project rate, this row turns amber with a warning triangle: the engine falls back to a rate the device supports, and recording and hardware input monitoring are disabled until you bring the two into agreement (open Session Settings and pick a supported rate — the warning offers a one-click switch).
Informational — shows how many CPU cores are available for audio processing.
If you connect a new audio device mid-session, AnalogDAW offers to Switch to it or Keep Current. If a device you were using disconnects, you're notified so you can pick a replacement in Audio Settings.
The Control Surface ▸ Configure… row opens the setup for external MIDI: hardware mixing/transport controllers (Mackie/MCU surfaces or generic MIDI controllers) and MIDI Clock sync for sequencers, arpeggiators, virtual MIDI ports, and hosted instruments. See Control Surfaces.
Next: Exporting & Sharing →