Ecasound Net-ECI Socket Disconnect Handling

This article examines how Ecasound manages socket disconnects during active Network Ecasound Control Interface (Net-ECI) sessions. It covers the socket detection mechanisms used by the control layer, the impact of sudden connection loss on active audio engine threads, error-handling routines such as SIGPIPE mitigation, and how Ecasound manages resource cleanup and process termination when a remote client drops off the network.

Net-ECI Communication Model

Net-ECI allows external applications to control the Ecasound engine over TCP/IP sockets using standard ECI commands. In this architecture, Ecasound acts either as a listening server waiting for incoming controller connections or as a client connecting to a remote endpoint. Communication is strictly synchronous on the control plane: the controlling application sends text commands, and Ecasound processes them and returns a response string followed by an acknowledgment token.

Detection of Disconnection

Ecasound detects socket disconnections through standard POSIX network I/O status checks:

  • Graceful Disconnects (EOF): When a client closes the socket cleanly, subsequent read operations on the socket return 0 bytes (indicating End-of-File). Ecasound's Net-ECI parsing loop identifies this as an intentional session closure.
  • Ungraceful Disconnects (Network Drops or Client Crashes): If the connection is severed without a proper TCP teardown (such as an unhandled crash or physical link failure), active reads fail with socket errors (such as ECONNRESET or ETIMEDOUT). If Ecasound attempts to write an output response to a dead socket, the operating system generates a SIGPIPE signal or returns an EPIPE error code.

Signal Handling and Crash Prevention

To prevent unhandled socket disconnects from crashing the main binary, Ecasound configures standard POSIX signal protections:

  • SIGPIPE Handling: Ecasound blocks or ignores SIGPIPE signals (or utilizes flags like MSG_NOSIGNAL where supported on socket writes). Instead of allowing a broken socket write to terminate the process via an unhandled signal, the system translates the failure into standard write error codes (EPIPE), allowing the Net-ECI control loop to execute controlled cleanup routines.

Audio Engine Behavior During Disconnects

Net-ECI decouples the user interface thread from the real-time audio processing engine. How the engine reacts depends on whether processing was actively underway:

  1. Processing in Progress: If the engine is in a running state (engine-status is running), the termination of the Net-ECI socket loop registers an abort condition for the session. Ecasound does not leave the audio engine running indefinitely in an unmonitored state; it initiates an internal engine-halt or stop routine.
  2. Audio Hardware Release: Once the engine halt is initiated, Ecasound closes active audio subsystems—such as ALSA, JACK, or OSS drivers. This prevents locked soundcard interfaces or dangling buffer states on external sound servers like JACK.

Session Cleanup and Process Lifespan

Because the standard Net-ECI implementation is designed around single-session management per instance, socket closure directly dictates the lifespan of the underlying Ecasound process:

  • Resource Deallocation: Dynamic memory assigned to the Net-ECI parser, string buffers, and chainsetup parameters are freed. File descriptors associated with input/output audio files are flushed and closed to prevent corrupted WAV, AIFF, or raw headers.
  • Process Exit: When the Net-ECI control loop breaks due to a socket error or EOF, Ecasound exits its main loop. By default, Ecasound terminates its execution completely rather than returning to a standalone listening state for a new client, requiring process supervisors (such as systemd, Docker, or custom wrapper scripts) to restart the binary if persistent availability is required.