Benchmark Ecasound Chainsetup Throughput

Benchmarking the maximum processing throughput of an Ecasound chainsetup requires measuring how much faster than real-time the audio engine can process effects, routing, and filters without being bottlenecked by hardware audio clocks or physical storage. This guide covers the essential tools and configurations used to stress-test and profile Ecasound setups, including native batch execution, system profiling utilities like GNU time and Linux perf, and RAM-backed I/O testing methods.

1. Ecasound in Batch Mode with Null Routing

To test the raw mathematical limits of a chainsetup, you must decouple Ecasound from sound card clocks (such as ALSA or JACK) and physical disk read/write constraints.

  • Native Batch Mode (-B:batch): Forces Ecasound to run continuously at the maximum speed the CPU allows rather than throttling to real-time playback rates.
  • Null Audio Targets (-o null): Prevents output audio rendering from introducing I/O latency.
  • Tone or Null Generators (-i tone,... or -i null): Creates synthetic, clock-free input streams of arbitrary duration to test complex effect chains (such as chains with multiple LADSPA plugins).

Example command for testing DSP throughput over a 60-second synthetic stream:

ecasound -B:batch -i:tone,sine,440,60 -o:null -ea:200 -efl:1000

2. GNU Time (/usr/bin/time)

The standalone GNU time utility measures the execution time and resource consumption of an Ecasound process, allowing you to calculate the Real-Time Factor (RTF).

Run the benchmark using the verbose flag:

/usr/bin/time -v ecasound -B:batch -i:input.wav -o:null -ea:150

Key metrics to analyze:

  • Elapsed (wall clock) time: Used to determine RTF. The formula is: \[\text{RTF} = \frac{\text{Audio Duration in Seconds}}{\text{Elapsed Wall Clock Time in Seconds}}\] An RTF of 10.0 means the chainsetup processes audio ten times faster than real-time.
  • Percent of CPU this job got: Shows whether Ecasound was able to fully saturate a CPU core.
  • Maximum resident set size (kbytes): Confirms that complex chains or plugins do not suffer from memory bloat.

3. Linux perf

Linux perf profiles the chainsetup at the hardware performance counter and kernel level, revealing whether bottlenecks stem from CPU cache limits, instruction pipeline stalls, or specific LADSPA plugins.

To gather general execution stats:

perf stat ecasound -B:batch -i:input.wav -o:null -el:comb,10,0.5

Key metrics to evaluate:

  • Instructions per cycle (IPC): Indicates computational efficiency. Low IPC during DSP execution often points to memory-access latency or branching issues inside specific LADSPA plugins.
  • L1-dcache-load-misses: Pinpoints whether large buffer sizes exceed CPU cache limits.

For a function-level breakdown of where CPU cycles are spent:

perf record -g ecasound -B:batch -i:input.wav -o:null -el:comb,10,0.5
perf report

4. In-Memory Filesystems (tmpfs)

When chainsetups require actual multi-channel WAV files instead of synthetic generators, physical disk read/write speeds can create false bottlenecks. Using a tmpfs partition isolates the audio processing engine from storage limits.

  1. Create a RAM disk:

    sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk

  2. Place test files into /mnt/ramdisk/.

  3. Route output directly to /mnt/ramdisk/output.wav.

This ensures that the elapsed time reflects pure DSP processing and memory-bus bandwidth.

5. Systematic Buffer Sweep Scripts

Ecasound's throughput fluctuates based on the internal buffer size configured via the -b:buffersize option. Smaller buffers increase CPU overhead due to frequent context switching and function calls, while excessively large buffers can overflow the L1/L2 CPU cache.

Use a Bash loop to benchmark throughput across standard power-of-two buffer sizes:

for b in 64 128 256 512 1024 2048 4096; do
    echo -n "Buffer size $b: "
    /usr/bin/time -f "%e seconds" ecasound -b:$b -B:batch -i:input.wav -o:null -ea:100 2>&1
done

The buffer size that yields the lowest elapsed time represents the optimal throughput configuration for that specific chainsetup and hardware architecture.