Ardour 9.0 on Linux in 2026: What Is New, What Matters in Real Projects, and a Stable Low Latency Configuration

Ardour 9.0 landed in early 2026 and it is the most consequential release since the 6.x rewrite. Not because of flashy features - Ardour has never been about flash - but because the changes address problems that actually blocked professional work on Linux. Better MIDI editing, a rewritten Lua scripting engine, overhauled latency compensation, and real improvements to session handling at scale. Here is what matters if you use Ardour for production work, and a tested configuration for stable low latency recording.

What changed in Ardour 9.0

MIDI editing overhaul

The MIDI editor was Ardour's weakest point for years. Version 9.0 adds:

• Piano roll velocity editing with a dedicated velocity lane below the note display, rather than the old color-coded approach. You can now draw velocity curves directly.
• Per-note articulation support through MIDI CC automation attached to individual notes rather than regions. This matters for orchestral template work.
• MPE (MIDI Polyphonic Expression) editing. If you use an MPE controller (Linnstrument, Sensel Morph, Roli), Ardour can now display and edit per-note pressure, slide, and pitch bend natively.
• Step input improvements. Step recording from a MIDI keyboard now respects the active grid quantization and can input chords by holding multiple keys.

Lua scripting engine rewrite

Ardour's Lua scripting was functional but slow and limited. The 9.0 engine:

• Uses LuaJIT where available (2-10x faster execution depending on the script)
• Exposes the full session API, including mixer strip parameters, plugin controls, and transport state
• Can run as real-time processors in the DSP chain (with careful programming)
• Supports import/export of session data in JSON format for interop with external tools

Practical use cases: automated gain staging across tracks, batch plugin parameter changes, custom metering, session template generation from spreadsheets.

Latency compensation rewrite

This is the change that matters most for recording. Previous Ardour versions had latency compensation that worked for simple signal paths but broke down with:

• Plugin chains where individual plugins reported different latencies
• Sidechain routing (compressor keyed from another track)
• Parallel processing buses with asymmetric plugin loads
• External hardware inserts via JACK/PipeWire send-return

Ardour 9.0 rewrote the latency graph traversal algorithm. Every signal path through the session is measured and compensated independently. The result is sample-accurate alignment even in complex routing topologies.

Verify latency compensation in your session:

Window > Latency Compensation Report

This new dialog shows the measured latency for every path in your session, any uncompensated segments, and warnings for paths that exceed the compensation buffer.

Session handling improvements

• Incremental save. Large sessions (100+ tracks) no longer freeze the UI during save. The session file is written incrementally in a background thread.
• Crash recovery improvements. The auto-backup system now saves a recovery snapshot every 60 seconds (configurable). On crash, Ardour offers to restore from the most recent snapshot rather than the last manual save.
• Template system overhaul. Session templates can now include plugin presets, routing, and bus structure. Creating a template from an existing session strips the audio but preserves everything else.

PipeWire vs JACK backend choice

Ardour supports three audio backends: ALSA, JACK, and PipeWire (via JACK compatibility). The choice matters.

PipeWire JACK (recommended for most users)

PipeWire provides a JACK-compatible API. Ardour connects to PipeWire as if it were a JACK server. This is the default on every major distribution in 2026.

Advantages:

• Desktop audio coexistence (browser, system sounds) without stopping Ardour
• Hot-plugging of audio devices
• Integration with WirePlumber for automatic routing
• PipeWire's quantum system handles buffer management

Disadvantages:

• Slightly higher scheduling jitter than native JACK2 at very low buffer sizes (quantum 32-64)
• PipeWire graph overhead for complex routing

For the detailed comparison, see the PipeWire vs native JACK analysis.

Native JACK2

Use native JACK2 only if:

• You need quantum 32 or 64 and PipeWire's scheduling jitter causes XRuns
• You are running a dedicated recording machine with no desktop audio needs
• You have a specific JACK-only tool in your signal chain that misbehaves with PipeWire

To run Ardour with native JACK2 in 2026, you need to stop PipeWire's JACK server first:

systemctl --user stop pipewire-jack.socket pipewire-jack.service
jackd -d alsa -d hw:0 -r 48000 -p 128 -n 2 &
ardour9

ALSA direct

The ALSA backend gives Ardour exclusive access to your audio interface. Lowest possible latency, no mixer overhead, but no other application can use the interface simultaneously.

Use this for dedicated tracking sessions where nothing else needs audio.

Session configuration for low latency recording

Here is a tested configuration for tracking with live monitoring through Ardour on PipeWire.

PipeWire configuration

Set a stable quantum that your hardware supports. If you have not measured your threshold, the quantum selection guide walks through the process.

# ~/.config/pipewire/pipewire.conf.d/ardour-session.conf
context.properties = {
    default.clock.rate = 48000
    default.clock.allowed-rates = [ 48000 96000 ]
    default.clock.quantum = 128
    default.clock.min-quantum = 64
    default.clock.max-quantum = 256
}

Ardour session settings

In Ardour's Session > Properties:

Setting	Value	Reason
Sample rate	48000 Hz	Matches PipeWire, no resampling
Buffer size	128 frames	Matches PipeWire quantum
Periods/buffer	2	Standard double-buffering
Monitoring	Ardour	Software monitoring through Ardour's mixer

If your interface has hardware monitoring (direct monitoring), use that instead for zero-latency input monitoring and set Ardour to "Hardware" monitoring mode. This bypasses the DAW entirely for the input signal and eliminates the round-trip latency concern during tracking.

Real-time priority

Ardour needs real-time scheduling priority. On a PipeWire system, this is typically handled by rtkit or direct rlimits configuration. Verify Ardour is getting RT priority:

# While Ardour is running
ps -eo pid,cls,rtprio,comm | grep ardour

You want to see FF (SCHED_FIFO) or RR (SCHED_RR) in the CLS column with a priority of 50 or higher. If you see TS (SCHED_OTHER), Ardour is not running with real-time priority and will XRun under load.

See the real-time scheduling guide for fixing this.

Buffer size recommendations

Workflow	Buffer (frames)	Latency at 48 kHz	Notes
Tracking with software monitoring	64-128	2.7-5.3 ms	Need RT kernel or PREEMPT_DYNAMIC
Tracking with hardware monitoring	256-512	5.3-10.7 ms	Latency does not affect monitoring
Overdubbing	128-256	5.3-10.7 ms	Plugin latency adds on top
Mixing	256-1024	5.3-21.3 ms	Stability over latency
Mastering	1024-2048	21.3-42.7 ms	Maximum headroom for heavy processing

During a session, you can change the buffer size in Ardour's Audio/MIDI Setup window. Ardour disconnects from the audio engine briefly, reconfigures, and reconnects. On PipeWire, you can also change the quantum at runtime:

pw-metadata -n settings 0 clock.force-quantum 256

This affects all JACK clients, not just Ardour. Use this for quick adjustments when switching from tracking to mixing within a session.

Plugin latency management

Individual plugins add processing latency. Convolution reverbs, linear-phase EQs, and look-ahead compressors are the biggest offenders. Ardour compensates automatically (the 9.0 rewrite makes this reliable), but you should know what your plugins are costing you.

Check plugin latency in Ardour:

Right-click plugin in mixer strip > Latency > Show reported latency

Or use the Latency Compensation Report window for the full picture.

Strategies for managing plugin latency:

During tracking: Remove or bypass all non-essential plugins on the monitoring path. Every plugin in the monitoring chain adds to the round-trip latency the performer hears.

During mixing: Plugin latency does not matter for playback because Ardour compensates by delaying other tracks to align. But extreme latency (convolution reverbs reporting 4096+ samples) can make the session feel sluggish when toggling plugins on and off.

Plugin bypass vs remove: Bypassing a plugin in Ardour still keeps it in the latency compensation graph. Removing it from the strip changes the compensation. Be aware of this when A/B comparing plugins.

Disk I/O optimization

Ardour reads audio from disk in real time. If disk I/O stalls, you get a dropout that sounds different from an audio buffer XRun - it is typically a longer gap or a repeat of the previous buffer's content.

For HDD systems, this is a real concern with high track counts. For NVMe SSDs, it rarely matters. But the configuration is worth getting right:

# Check your disk scheduler
cat /sys/block/nvme0n1/queue/scheduler
# For NVMe, 'none' is correct (no scheduler needed)
# For SATA SSDs, 'mq-deadline' or 'none'
# For HDDs, 'bfq' with audio priority

# Set read-ahead for audio drive
sudo blockdev --setra 2048 /dev/nvme0n1

In Ardour's Preferences > Performance:

Setting	Recommendation
Playback buffer (seconds)	5.0 (default is fine for SSDs, increase for HDDs)
Recording buffer (seconds)	5.0
Disk I/O threads	Leave at default unless you have 100+ tracks

For sessions stored on network drives (NFS, SMB), increase the playback buffer to 10-15 seconds. Network latency spikes will cause dropouts at lower values.

Large session stability

Ardour 9.0 handles large sessions better than any previous version, but "large" is relative. Here are the practical limits and how to work within them:

Session size	Track count	Plugin instances	Expected behavior
Small	1-24	0-50	No issues on any reasonable hardware
Medium	25-64	50-150	May need buffer increase for mixing
Large	65-128	150-400	CPU becomes the bottleneck, use bus processing
Very large	128+	400+	Requires discipline with CPU management

For large sessions:

• Freeze tracks that are finalized. Freezing renders the track with all plugins to a temporary audio file, freeing the CPU.
• Use bus processing instead of per-track plugins. One EQ on a drum bus is cheaper than eight EQs on eight drum tracks.
• Disable tracks that are not actively being worked on. Disabled tracks use no CPU.
• Check thread utilization. Ardour distributes DSP processing across threads. Monitor with:

pw-top

The pw-top walkthrough shows how to read the output and identify CPU bottlenecks.

Comparison with REAPER on Linux

Both Ardour and REAPER run on Linux. Here is how they compare for practical recording work:

Feature	Ardour 9.0	REAPER 7.x
License	GPL (free/donation)	Commercial ($60/$225)
Native Linux build	Yes	Yes (official)
PipeWire JACK support	Yes	Yes
ALSA direct backend	Yes	Yes
MIDI editing	Good (improved in 9.0)	Excellent
Plugin format support	LV2, VST2, VST3, AU, LADSPA	VST2, VST3, LV2 (via extension)
Latency compensation	Sample-accurate (9.0 rewrite)	Sample-accurate
Scripting	Lua	ReaScript (EEL, Lua, Python)
Large session handling	Good	Excellent
Video editing integration	Basic	Good
Surround/immersive audio	9.0 adds Atmos basics	Full Atmos support
Community	Open-source community	Large user community

Ardour wins on plugin format breadth (LV2 and LADSPA are Linux-native formats with huge libraries), open-source transparency, and the fact that it is free. REAPER wins on scripting flexibility, MIDI editing workflow, and handling very large sessions with many takes and comping.

For most Linux recording workflows, either works well. Choose based on your specific needs and whether the GPL matters to you.

FAQ

Can I use Ardour with PipeWire and have other audio playing? Yes. PipeWire handles mixing Ardour's JACK audio with desktop audio automatically. No configuration needed. The PipeWire quantum will be driven by Ardour's buffer size request.

Should I use 48 kHz or 96 kHz? 48 kHz for most work. 96 kHz only if you are recording acoustic instruments and plan to do significant pitch shifting or time stretching in post. The higher rate doubles CPU and disk usage for negligible audible benefit in most scenarios.

My plugins show different latency values in Ardour 9.0 vs 8.x. Is this a bug? Probably not. The 9.0 latency compensation rewrite may measure plugin latency more accurately. If the numbers are close (within a few samples), the new values are likely correct.

How do I import sessions from other DAWs? Ardour imports AAF and OMF session interchange formats. REAPER sessions can be partially imported via the AAF export in REAPER. There is no direct Ableton or Logic import.

Ardour says my plugin is "not authorized." What? Some commercial plugins (Waves, iZotope) use license checks that fail on Linux. This is a plugin vendor issue, not an Ardour issue. Check if the vendor supports Linux. Many do not.

How much RAM do I need? Ardour itself is lightweight - 500 MB for a modest session. RAM usage scales with plugin instances (some sample-based instruments load gigabytes into memory) and track count. 16 GB is comfortable for most work. 32 GB if you use large sample libraries.

Conclusion

Ardour 9.0 is a genuine step forward for professional recording on Linux. The latency compensation rewrite alone justifies the upgrade for anyone doing complex routing or hardware insert work. Configure PipeWire to match your session rate, set a quantum your hardware can sustain, verify real-time priority is working, and manage your plugins during tracking to keep the monitoring path lean. The low latency checklist covers the full system-level setup, and the latency measurements show what to expect from specific hardware configurations.