How to Fix Ecasound Audio Buffer Underruns

Audio buffer underruns in Ecasound, commonly known as xruns, occur when the audio subsystem requests audio data that the application has not finished processing in time. This article explores the root causes of these interruptions—including inadequate buffer sizing, real-time thread scheduling issues, and high system latency—and details the precise command-line parameters and system configurations required to eliminate them for reliable, artifact-free audio processing.

What Causes Buffer Underruns in Ecasound

An audio buffer underrun happens when the digital-to-analog converter (DAC) consumes samples from the output ring buffer faster than Ecasound can write them. When the buffer empties completely, the hardware plays silence or discontinuous data, resulting in audible clicks, pops, or dropped audio.

The primary causes in Ecasound include:

• Undersized Buffers: Configuring an audio buffer size too small for the host CPU to process incoming effects or routings within the required period.
• Lack of Real-Time Scheduling: Running Ecasound as a regular user thread without real-time kernel priorities, leaving it vulnerable to CPU preemption by background operating system tasks.
• Heavy DSP Loads: Complex multi-track setups, high-latency LADSPA plugins, or real-time resampling that exceed CPU cycle limits per audio period.
• System Latency and I/O Bottlenecks: Disk write contention when recording multi-channel uncompressed audio, or slow interrupt handling caused by power-saving CPU governors.
• Mismatches in the Audio Chain: Parameter conflicts between Ecasound's internal buffers and underlying sound architectures like ALSA or JACK.

Parameters to Eliminate Underruns

Adjusting specific Ecasound flags allows you to expand processing headroom, balance latency against stability, and elevate thread priority.

1. Increase the Audio Buffer Size (-b)

The -b parameter sets the processing buffer size in sample frames. The default value is often too aggressive for complex chains on non-optimized systems.

Increasing this value gives the CPU more time to fill the buffer before the sound card demands the next frame:

ecasound -b:1024 -i:input.wav -o:alsa

• Low latency (risk of xruns): -b:128 or -b:256
• Standard stability: -b:512 or -b:1024
• High reliability (mixing, playback, slow systems): -b:2048 or -b:4096

2. Enable Real-Time Scheduling (-r)

To prevent the Linux kernel from starving Ecasound of CPU time, enable POSIX real-time scheduling using the -r flag followed by an optional priority level (1–99, default is often 50):

ecasound -r:50 -b:512 -i:input.wav -o:alsa

Note: For the -r parameter to function, your user account must have permission to set real-time priorities in /etc/security/limits.conf (via rtprio and memlock).

3. Tune Buffering Modes (-z)

Ecasound provides the -z family of parameters to modify low-level engine behaviors:

• -z:db (Double Buffering): Enables double buffering between the engine and audio objects. This decouples signal processing from audio device I/O, dramatically reducing underruns during disk reads/writes.
• -z:intbuf: Sets internal engine buffer sizes explicitly if default internal allocations fail to match external hardware drivers.
• -z:nopsched: Disables real-time thread scheduling optimizations if your operating system uses a custom real-time kernel where Ecasound's automated scheduling causes thread lockups or priority inversions.

Example enabling double buffering with real-time priority:

ecasound -z:db -r:60 -b:1024 -i:input.wav -o:alsa

Complementary System Adjustments

If adjusting Ecasound parameters alone does not eliminate underruns:

• Set the CPU Governor to Performance: Dynamic frequency scaling can cause dropouts during frequency state changes. Set all CPU cores to maximum frequency using:

  cpupower frequency-set -g performance

• Use JACK as the Audio Subsystem: When low latency is required alongside zero underruns, route Ecasound through a properly tuned JACK daemon using -i:jack and -o:jack. Configure JACK's periods (-n 2 or -n 3) and frame size (-p 512) independently to handle the hardware timing layer.