Configure Ecasound ALSA Buffer Size and Periods

Ecasound manages ALSA audio driver performance by mapping its internal processing frame sizes directly to ALSA period sizes, while negotiating buffer counts through ALSA's hardware parameter interfaces and user-defined PCM configurations. By adjusting the global -b processing parameter, disabling internal double-buffering, or defining custom hardware slaves in ALSA configuration files, users can precisely regulate period size, period counts, and total buffer latency to eliminate dropouts and minimize roundtrip delay.

The Role of the Internal Buffer Flag (-b)

Ecasound sets the ALSA driver’s period size using the -b:frames command-line option. The value specified after -b sets the internal processing chunk size in sample frames. During hardware initialization, Ecasound passes this value to the ALSA library using snd_pcm_hw_params_set_period_size_near().

Because ALSA hardware operates in discrete fragments or periods, matching Ecasound’s internal buffer size directly to the ALSA period size ensures that every write or read cycle corresponds to exactly one hardware interrupt. If a sound card cannot support the exact requested frame size, ALSA rounds to the nearest supported hardware value, which Ecasound then adopts for its processing loop.

How Ecasound Determines Period Counts

Ecasound does not feature a dedicated, standalone command-line flag specifically named for setting ALSA period counts (fragments). Instead, it negotiates the buffer size and period count using ALSA’s runtime hardware constraints:

1. Automatic Hardware Negotiation: When Ecasound sets the period size via -b, the ALSA driver typically assigns a default period count—frequently 2 (double buffering) or 3 (triple buffering)—depending on the sound card's architecture and kernel driver.
2. Total Buffer Allocation: The driver calculates the total hardware buffer size using the formula:
   Total Buffer Size = Period Size × Period Count.
   If the sound card requires a minimum buffer capacity to prevent underruns, ALSA will raise the period count automatically to fulfill the hardware's requirements.

Explicit Period and Buffer Configuration via ALSA

When exact control over both period size and period count is required, the standard approach is to define a custom PCM device in ~/.asoundrc or /etc/asound.conf, and then route Ecasound through that device.

A custom hardware definition explicitly defines both constraints:

pcm.low_latency {
    type hw
    card 0
    device 0
    subdevice 0
    mmap_emulation 0
    period_size 128
    periods 2
}

To use this configuration within Ecasound, supply the custom ALSA PCM identifier as the input or output target:

ecasound -b:128 -i:alsa,low_latency -o:alsa,low_latency

Setting -b:128 ensures Ecasound's processing engine works synchronously with the 128-frame period size declared in the ALSA profile, while ALSA strictly enforces the 2-period limit.

Optimizing Latency with Engine Buffering Flags

In addition to ALSA hardware buffers, Ecasound provides engine-level buffering flags that influence how data moves into driver buffers:

• -z:nodb (Disable Double Buffering): By default, Ecasound maintains an internal queue between its processing engine and the ALSA output threads. Supplying -z:nodb removes this software buffer, forcing the engine to write directly into the ALSA hardware ring buffer. This reduces overall throughput latency, but it requires that both the -b period size and CPU processing headroom are sufficient to prevent xruns (buffer underruns/overruns).
• -z:intbuf (Enable Intermediate Buffering): When processing demands vary dynamically, intermediate buffering provides additional elasticity between Ecasound’s signal chain and the ALSA driver, protecting against dropouts at the expense of added latency.

Latency Calculation

The total hardware latency introduced by ALSA when running under Ecasound can be calculated with:

\[\text{Latency (seconds)} = \frac{\text{Period Size} \times \text{Period Count}}{\text{Sampling Rate (Hz)}}\]

For example, running Ecasound at 48,000 Hz with -b:256 and an ALSA device configured for 2 periods produces a hardware latency of:

\[\frac{256 \times 2}{48000} \approx 0.01066 \text{ seconds (10.66 ms)}\]