How Ecasound Handles Dynamic Sample Rate Changes

This article examines how the Ecasound multitrack audio processing utility responds when an underlying audio interface or soundcard requests dynamic sample rate switching. Due to Ecasound's design, which relies on a unified, static chainsetup configuration during active engine processing, the software does not support seamless on-the-fly sample rate switching. Instead, handling such events requires either session-level reinitialization, external resampling layers, or manual chainsetup reconfiguration.

Static Engine Architecture

Ecasound’s core processing engine requires all audio inputs, outputs, and intermediate operators to operate at a fixed, uniform sample rate during execution. This parameter is defined globally for a chainsetup, typically specified via the audio format option (such as -f:sample_format,channels,sample_rate) or inherited from an audio server.

Internal buffer sizes, envelope followers, oscillator states, and time-dependent DSP filters are initialized specifically to this fixed sampling frequency. Because there is no internal continuous resampling layer built directly into the signal chains, the engine cannot adapt to a soundcard that suddenly negotiates a new sample rate mid-stream.

ALSA Driver Level Behavior

When using the Advanced Linux Sound Architecture (ALSA) output or input modules directly (alsa or alsahw), Ecasound requests hardware access based on its initialized parameters.

If the underlying soundcard attempts to enforce a new sample rate, or if an external clock source causes the hardware clock to shift:

• Hardware mismatch: The ALSA API returns an I/O error or device configuration error to Ecasound.
• Engine halt: Ecasound cannot dynamically renegotiate the stream parameters while the engine is running. Consequently, the processing loop breaks, leading to an engine stop or a fatal stream error.

To mitigate this at the ALSA level without stopping Ecasound, users often rely on ALSA’s plug layer (-i:alsaplug:default or -o:alsaplug:default). The plug plugin provides a static rate to Ecasound while handling software rate conversion against whatever rate the hardware accepts, though this still assumes the requested rate from Ecasound’s perspective remains constant.

JACK and Modern Audio Servers

When paired with the JACK Audio Connection Kit, Ecasound relies entirely on the JACK graph's global sample rate.

• If the JACK server's sample rate is changed dynamically (for instance, via an external master word-clock change or server reconfiguration), JACK notifies all connected clients.
• Ecasound does not dynamically rebuild its active DSP objects to match this notification mid-run.
• The mismatch typically results in the engine either dropping from the JACK graph, throwing buffer processing errors, or outputting pitch-shifted/distorted audio due to the unexpected buffer time step.

Modern servers like PipeWire automatically provide transparent, high-quality resampling wrappers that emulate ALSA and JACK interfaces. When a physical soundcard changes sample rates under PipeWire, PipeWire handles the dynamic conversion behind the scenes, presenting a stable, unchanged sample rate to the running Ecasound instance.

Programmatic Reconfiguration via ECI

To accommodate planned or external sample rate changes cleanly, you must control Ecasound via the Ecasound Control Interface (ECI) through interactive commands or scripting (Python, C, Perl, or Bash):

1. Stop the engine: Issue stop to halt audio processing.
2. Disconnect the chainsetup: Use cs-disconnect to release the audio device.
3. Update parameters: Re-declare the audio format with the new sample rate via format commands (e.g., cs-set-param).
4. Reconnect and restart: Execute cs-connect followed by start to reallocate internal buffers and resume processing at the new sample rate.