Ecasound Duplex Across Different Sound Cards

Ecasound manages duplex recording and playback across different physical sound cards by decoupling audio inputs and outputs into independent chainsets within a single processing engine. Because separate physical audio interfaces rely on distinct hardware crystal oscillators, operating them simultaneously introduces clock drift and synchronization challenges. Ecasound resolves this through flexible device routing, configurable buffer management, and integration with external frameworks like ALSA aggregate devices or the JACK Audio Connection Kit.

The Chainsetup Architecture

At the core of Ecasound is the chainsetup, an engine architecture that routes audio signals between independent inputs and outputs through intermediate chains. Unlike applications that require an audio interface to provide a single full-duplex handle, Ecasound assigns inputs (-i) and outputs (-o) per chain (-a).

To run duplex across two cards, Ecasound attaches one physical device to a recording chain and a different physical device to a playback chain:

ecasound -a:rec -i:alsahw,1,0 -o:recording.wav -a:play -i:playback.wav -o:alsahw,2,0

In this setup, the engine processes audio frames synchronously during each engine cycle. The capture stream from Card 1 and the playback stream to Card 2 are evaluated in parallel inside the main execution loop.

Addressing the Clock Drift Problem

When two separate sound cards run in parallel, their hardware sample clocks naturally drift apart. Card 1 might record at 44,100.05 Hz while Card 2 plays back at 44,099.92 Hz. Over time, this discrepancy leads to buffer underruns (xruns), buffer overflows, or progressive latency mismatches.

Ecasound does not perform real-time adaptive sample rate conversion (resampling) natively within its internal ALSA driver. Instead, managing cross-card duplex stability requires specific configuration layers:

1. Engine Buffer Alignment

Ecasound allows granular control over engine buffers via the -b:buffersize and -z:feature flags. Setting a larger buffer size helps mitigate short-term jitter between the two devices. Double-buffering (-z:db) can be enabled to give the read and write threads more tolerance against timing deviations before an xrun occurs.

2. ALSA Virtual Devices (asym Plugin)

To avoid managing separate device threads manually, users can define an asymmetric virtual device inside the Linux ALSA configuration file (~/.asoundrc). The ALSA asym plugin combines the capture interface of one card and the playback interface of another into a single logical, full-duplex device:

pcm.duplex_cards {
    type asym
    playback.pcm "hw:1,0"
    capture.pcm "hw:2,0"
}

Ecasound can then target this virtual device directly using -i:alsa,duplex_cards and -o:alsa,duplex_cards. ALSA handles the underlying stream routing, while Ecasound treats the setup as a standard full-duplex interface.

3. JACK Audio Connection Kit Integration

For professional environments requiring strict drift compensation, Ecasound operates as a client to the JACK audio server. In this configuration, JACK drives the master sound card, and a utility such as zita-ajbridge (providing zita-a2j and zita-j2a) connects the secondary sound card to the JACK graph.

The zita-ajbridge tool utilizes dynamic resampling to continuously compensate for the clock difference between the two physical cards. Ecasound then binds to JACK ports using -i:jack and -o:jack, achieving stable, drift-free duplex operation across disparate hardware interfaces.