Route Audio Between Two Interfaces Using Ecasound

Ecasound can route audio directly between two separate physical audio interfaces on Linux without requiring a full digital audio workstation. By defining independent input and output devices within its flexible routing chain architecture, Ecasound reads real-time PCM data from one hardware interface and writes it directly to another. This guide explains how this setup works, provides the commands necessary to achieve it, and highlights important considerations regarding clock synchronization.

How Ecasound Handles Multiple Interfaces

Ecasound treats audio inputs and outputs as modular endpoints. Because it interacts directly with audio subsystems like ALSA, OSS, or JACK, it does not require input and output streams to share the same physical hardware device.

In an ALSA-based Linux system, each physical interface is assigned a specific card and device index. Ecasound can open one card explicitly for capture and a completely different card for playback within a single processing engine.

Identifying Your Audio Devices

Before executing a route, determine the hardware identifiers for both interfaces using ALSA's command-line tools:

arecord -l   # Lists capture devices
aplay -l     # Lists playback devices

Look for the card numbers corresponding to your target hardware (for example, Card 1 as the source and Card 2 as the destination).

The Routing Command

To route audio from the capture interface to the playback interface, invoke Ecasound by specifying the input (-i) and output (-o) device paths:

ecasound -f:s16_le,2,48000 -i alsa,plughw:1,0 -o alsa,plughw:2,0

Breaking down the parameters:

Latency and Buffer Configuration

To control latency and prevent buffer overruns or underruns (xruns), configure the buffer size manually using the -b flag:

ecasound -b:256 -f:s32_le,2,48000 -i alsa,hw:1,0 -o alsa,hw:2,0

Using direct hw:X,Y rather than plughw:X,Y minimizes CPU overhead and latency, but it requires that both interfaces natively support the exact sample format and sample rate defined by the -f parameter.

Clock Drift Considerations

When running two independent physical sound cards, each device relies on its own internal crystal oscillator. Because two physical clocks never run at the exact same speed, clock drift will occur over extended runtimes.

If run continuously for hours, the input and output pointers may slowly desynchronize, eventually causing an audible click, dropout, or xrun. If your deployment requires uninterrupted 24/7 routing between distinct hardware cards without hardware word-clock synchronization, an audio server capable of dynamic resampling (such as PipeWire or JACK combined with zita-a2j) should be placed between the cards, with Ecasound connecting through that layer. For short-term capture, monitoring, or testing, Ecasound's direct ALSA routing works immediately out of the box.