Ecasound Net-ECI Multiple Client Connections

This article examines whether multiple external client applications can connect concurrently to a single Ecasound Net-ECI (Network Ecasound Control Interface) instance. It details the architectural limitations of the Net-ECI server, explains the underlying constraints regarding concurrency, and outlines practical solutions and workarounds for managing multiple controllers in an Ecasound-based audio pipeline.

By default, a single Ecasound Net-ECI instance cannot accept concurrent connections from multiple external client applications. When Ecasound runs in server mode (typically via the --server option, listening on a designated TCP port), its built-in network handler is designed to service only one client session at a time. Once an external client establishes a connection to the Net-ECI socket, the port becomes busy, and any subsequent connection attempts from other clients will either block or fail until the active client closes its connection.

This restriction is tied directly to Ecasound's internal design. The Ecasound Control Interface (ECI) functions as a stateful, procedural engine. Commands alter global engine states, such as the active chainsetup, input/output assignments, and playback or recording status. Because the core engine is not designed to negotiate conflicting commands or maintain isolated session states across multiple independent actors, concurrent multi-client access is natively prohibited to prevent state corruption and race conditions during real-time audio processing.

If your setup requires multiple applications to control a single Ecasound instance, you must implement architectural workarounds outside of Ecasound itself:

  1. Transient (Short-Lived) Connections: Instead of keeping persistent TCP connections open, clients can connect, send a batch of commands, receive the responses, and immediately close the socket. This allows multiple applications to share the server sequentially, provided they implement proper retry logic in case another client is momentarily connected.

  2. Custom Middleware or Proxy: The most robust solution is to place a centralized daemon (written in Python, Node.js, or C) between the clients and Ecasound. The proxy maintains a single persistent Net-ECI connection to Ecasound while exposing its own API (such as REST, WebSocket, or MQTT) to external applications. This middleware can serialize incoming requests, resolve command conflicts, and broadcast Ecasound status updates to all connected clients simultaneously.

  3. Multiple Ecasound Instances: If the external applications control separate, unrelated audio chains, run multiple Ecasound instances bound to distinct TCP ports. Each client can then maintain a dedicated, persistent Net-ECI session with its own assigned Ecasound daemon.