Ecasound Behavior When Audio Interface Disconnects

When an external audio interface is disconnected while Ecasound is actively processing audio, the underlying audio subsystem abruptly loses its communication endpoint. This unexpected removal triggers low-level I/O errors, causes Ecasound to immediately halt its processing engine, and can leave recording files with incomplete headers. Because Ecasound cannot dynamically hot-swap or re-attach hardware devices during an active chainsetup, the processing session terminates in a failure state.

Driver-Level Failure Detection

Ecasound relies on audio backends such as ALSA (Advanced Linux Sound Architecture) or JACK to communicate with hardware. When a USB or FireWire audio interface is unplugged, the operating system removes the associated device node.

• Direct ALSA Mode: If Ecasound is accessing the hardware directly via ALSA (-i:alsa or -o:alsa), the ALSA subsystem immediately returns an input/output error—typically ENODEV (No such device) or EIO (I/O error)—upon the next read or write attempt.
• JACK Mode: If Ecasound routes through a JACK audio server (-i:jack or -o:jack), the failure impacts JACK first. The JACK daemon loses its hardware device, often causing jackd to crash, enter an unrecoverable error loop, or trigger a shutdown callback to all attached clients.

Engine Reaction and Process State

Once the low-level failure is returned to Ecasound's processing loop, the engine's real-time thread breaks:

1. Error Logging: Ecasound emits critical error messages to standard error (stderr), identifying broken pipes, buffer underruns/overruns, or failure to read/write from the specified audio object.
2. Engine Halt: The internal processing loop halts. Ecasound does not hang indefinitely; it terminates the active chain execution to avoid runaway CPU loops.
3. Execution Mode Outcome: In non-interactive batch mode, Ecasound exits back to the terminal shell with a non-zero exit status. In interactive mode (Ecasound CLI), the engine stops running, returning control to the interactive prompt where the chainsetup is marked as stopped or invalid.

File Integrity and Unfinalized Containers

If Ecasound was routing input from the disconnected interface directly to disk, the interruption impacts file integrity:

• Headered Formats (e.g., WAV): File formats that require container headers to declare the total length of the audio chunk will not be updated properly. While the captured raw PCM data remains on disk up to the point of disconnection, the WAV header will typically show a file size of zero or an incorrect sample count. These files often require repair tools (such as sox or ffmpeg) to reconstruct the headers before standard media players can read them.
• Raw Formats: Headerless formats (like raw PCM) retain all audio written up to the final buffered block prior to the disconnect.

Recovery and Session Restarting

Ecasound lacks automatic reconnect or hot-plug recovery capabilities. Re-plugging the interface while Ecasound is running will not resume processing.

To restore operation, the user must wait for the operating system to re-enumerate the device, restart any intermediary servers (such as jackd or PipeWire) if they crashed, and manually re-initialize the Ecasound chainsetup from the terminal or interactive interface.