Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 3 of 3

Thread: Why is the audio library block instead of sample based

  1. #1
    Junior Member
    Join Date
    Sep 2018

    Why is the audio library block instead of sample based

    I think the question is quite clear. Why was the audio library designed to be block based instead sample based?

    As it is now the library processes multiple samples per update instead of single samples.

  2. #2
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Colmar, France
    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.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    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.
    Last edited by PaulStoffregen; 11-02-2018 at 08:19 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts