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:10002. 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:150Key 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.5Key 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 report4. 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.
- Create a RAM disk:
sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk - Place test files into
/mnt/ramdisk/. - 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
doneThe buffer size that yields the lowest elapsed time represents the optimal throughput configuration for that specific chainsetup and hardware architecture.