Configuring PipeWire Pro-Audio Nodes for Ultra-Low Latency Live Kernel Audio Routing

핵심 내용

• Set the quantum explicitly. The default quantum is large for desktop use; pro-audio sessions need 64 or 128 frames at the target sample rate.
• Pin the sample rate. Avoid automatic rate switching mid-session, which causes resampling artifacts and xruns.
• Choose a stable clock source. Use the hardware clock of the primary interface, not the system clock, for sample-accurate timing.
• Raise process priority. PipeWire and the audio clients need real-time scheduling; configure rtkit or a real-time group.
• Isolate the audio CPU. Dedicate a core to audio processing with isolcpus or cgroup cpuset to avoid scheduler interference.
• Measure round-trip latency. Use jack_iodelay or a loopback test to verify the configured latency matches reality.
• Monitor xruns. Track underrun counts in PipeWire logs and alert before they become audible.
• Keep buffer headroom. A slightly larger quantum with zero xruns beats a smaller one that drops samples.

Architecture

The audio path runs from the application through PipeWire's graph into the kernel ALSA driver and back. The quantum sets how many samples are processed per cycle, the clock source anchors timing, and the scheduler determines whether cycles complete on time. Pro-audio tuning shrinks the quantum while guaranteeing that every cycle finishes.

Production configuration

# /etc/pipewire/pipewire.conf.d/10-pro-audio.conf
context.properties = {
    default.clock.rate = 48000
    default.clock.quantum = 128
    default.clock.min-quantum = 64
    default.clock.max-quantum = 256
    default.clock.force-rate = true
}

# /etc/security/limits.d/99-audio.conf
@audio - rtprio 95
@audio - memlock unlimited
@audio - nice -19

# kernel boot parameter for CPU isolation
isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3

pw-jack jack_iodelay
# or with a loopback cable:
pw-loopback -n loopback-test
# check xrun counts
pw-top
journalctl -u pipewire --since '10 min ago' | grep -i xrun

Edge cases from production

• USB audio interfaces add variable latency; measure per device rather than trusting the configured quantum.
• Bluetooth audio cannot achieve pro-audio latency; use a wired interface for live work.
• High CPU load from plugins causes xruns even with a correct quantum; profile the DSP load separately.
• Rate switching by a consumer app resets the quantum; lock the rate in the server config.

자주 묻는 질문