Why is the audio library block instead of sample based
- Thread starter adge
- Start date
- Status
Theremingenieur
Senior Member+
It’s simply for efficiency. Processing many samples within one single interrupt reduces the cpu cycle overhead for storing/retrieving the core registers on the stack and it allows the compiler to optimize the use of the core registers and thus to reduce the waste of cpu cycles for load and store operations, especially when using the ARM thumb2 DSP extension opcodes.
PaulStoffregen
Well-known member
Block processing also gives us great compatibility with other libraries and code using interrupts. Details vary depending on which inputs & outputs you choose and how much of the total CPU time your processing uses, but generally we can tolerate considerable interrupt latency imposed by other code accessing other non-audio hardware with interrupts, and at the same time we can do most of the work at a low interrupt priority, so we impose very little latency on most other the interrupts. The audio is very resilient to disruption by other code. Even OneWire and short LED strips & rings with Adafruit_NeoPixel can usually be used (though we do have better alternative non-blocking addressable LED libs available on Teensy).
If you run 1 interrupt per sample at 44.1 kHz, that's only ~22 microseconds to do whatever work is needed. Consider what happens if another interrupt blocks it for 5 to 10 microseconds (very common). Or 50 to 100 us (less well behaved libraries) will cause you to miss multiple samples. This way imposes a heavy burden on all other interrupts, and can tolerate very little extra latency from other code using interrupts. Audio done this way is very brittle and easily glitched if you add other code & libraries into the mix.
And yes, it's vastly more efficient as Theremingenieur explained. We can do so much more, and do it with great compatibility with nearly all Arduino libraries.
If you run 1 interrupt per sample at 44.1 kHz, that's only ~22 microseconds to do whatever work is needed. Consider what happens if another interrupt blocks it for 5 to 10 microseconds (very common). Or 50 to 100 us (less well behaved libraries) will cause you to miss multiple samples. This way imposes a heavy burden on all other interrupts, and can tolerate very little extra latency from other code using interrupts. Audio done this way is very brittle and easily glitched if you add other code & libraries into the mix.
And yes, it's vastly more efficient as Theremingenieur explained. We can do so much more, and do it with great compatibility with nearly all Arduino libraries.
Last edited:
- Status