Ecasound with ALSA dmix and dsnoop

Ecasound interacts with ALSA plugin layers such as dmix (direct mixing for playback) and dsnoop (snooping for capture) by interfacing through the ALSA user-space library (libasound) rather than accessing the raw hardware drivers directly. This architectural design allows Ecasound to treat virtual ALSA PCM plugins as standard input and output nodes, enabling concurrent software mixing, simultaneous stream capture, and format translation across multiple applications sharing a single sound card.

ALSA Device Addressing in Ecasound

Ecasound interfaces with ALSA devices using its standard input (-i) and output (-o) object parameters. The syntax takes the form of -i alsa,pcm_device_name or -o alsa,pcm_device_name.

When a user specifies a raw hardware device—such as -o alsa,hw:0,0—Ecasound requests direct, exclusive access to the sound card's hardware buffer. If another process is using that device, the request fails. To bypass hardware exclusivity, Ecasound can target virtual ALSA devices configured via ~/.asoundrc or /etc/asound.conf that invoke the dmix or dsnoop plugins, or invoke the plugins directly using ALSA's standard string syntax (for example, -o alsa,plug:dmix).

Playback Handling with dmix

The dmix plugin allows multiple user-space applications to mix down multiple audio streams into a single hardware playback stream. When routed to a dmix node:

1. Software Mixing: Ecasound feeds rendered audio frames into the shared memory segment managed by the dmix plugin.
2. Buffer Synchronization: The dmix layer handles the synchronization with the hardware clock, meaning Ecasound’s internal engine does not control the physical card’s hardware period interrupts directly.
3. Format Wrapping: Because dmix strictly enforces fixed parameters (typically 48kHz or 44.1kHz, stereo, signed 16-bit little-endian), Ecasound handles variations best when paired with ALSA's plug layer (e.g., plug:dmix). The plug layer transparently resamples and remaps channels before passing the data to dmix.

Capture Handling with dsnoop

Similar to dmix, the dsnoop plugin splits a single hardware capture stream across multiple listening processes. When Ecasound uses a dsnoop device (e.g., -i alsa,plug:dsnoop):

1. Non-Exclusive Capture: Multiple Ecasound instances or background recorders can capture audio from the same microphone or line-in simultaneously.
2. Stream Distribution: dsnoop maintains a single master capture stream from the hardware and distributes copies of the captured samples to each connected application's ring buffer.
3. Clock Dependency: Ecasound reads data at the rate dictated by dsnoop. If Ecasound processing stalls or buffer overruns occur, they are isolated to the specific client buffer without interrupting other processes reading from the same dsnoop master.

Managing Buffers and Real-Time Constraints

Using dmix and dsnoop introduces specific constraints that affect Ecasound’s operation:

• Buffer and Period Size Matching: Ecasound allows users to configure the internal buffer size via the -b:buffersize option. If this buffer size conflicts with the fixed period size of the dmix or dsnoop slave definition, ALSA may return an Invalid argument (EINVAL) error. Matching Ecasound’s buffer size to the ALSA configuration avoids period mismatch errors.
• Latency Overhead: Bypassing hw: in favor of dmix and dsnoop introduces intermediate buffering, slightly increasing round-trip latency. For non-realtime or mixed-desktop workloads, this latency is negligible, but for strict low-latency monitoring, direct hardware access (hw:) or JACK is preferred over ALSA software plugins.
• Full-Duplex Operation: To achieve simultaneous recording and playback with shared access, Ecasound must bind to an asym ALSA device—a virtual device that routes playback to dmix and capture to dsnoop. By specifying -i alsa,default and -o alsa,default on modern Linux configurations, Ecasound automatically utilizes the underlying asym routing without requiring custom session configurations.