I want to implement an audio effect that reacts to an external parameter that varies over time. The book I have describes an effect in a function that processes a certain framesize of the audio input. But using 1024 samples or more might be too slow to react on the external parameter, since it would only change all 1024 samples. In the MATLAB simulation I am passing a pre-computed array to the function. Now I want to implement this on a DSP.

One solution I can think of is using a global variable and a multihreaded application. One thread writes the current paramenter to the global variable and the other thread processes the effect filter only with that current variable. That way I would not have to pass an array every time and always have the up-to-date parameter.

Another way would be calling the function every few samples. Since it is based on a second-order filter, the minimum I need is three samples. This would also be more than enough for the parameter.

Is there a standard way to go about in digital audio processing?


Typically this requires a trade off between CPU efficiency and latency. Frame based signal processing incurs at least one frame of latency and it you are planning to play live through the effect, you need to keep this quite low otherwise it get's distracting.

On the other hand, frame-based processing is way more efficient than sample by sample processing, since you can use DMA, vector instructions, highly optimized loops etc and you can amortize setup (coefficient calculation and loading, loading and storing of states, etc.) over the entire frame.

For live audio effects which moderate algorithmic complexity, something like 32 or 64 samples at 44.1 kHz or 48 kHz typically is a good starting point.

  • $\begingroup$ Okay thank you. I will try that now. If the result is not satisfying I can still change it. I am just worried about the normalization. Normalizing frame by frame might sound weird. $\endgroup$
    – neolith
    Jan 1 at 17:19
  • $\begingroup$ uhm, nomenclature is not always agreed on. but i would leave the term "frame" for processes like a phase vocoder or sinusoidal modeling or STFT and the framelength is usually the same as the window size. however the hoplength is not usually the framelength. if 50% overlap, the hoplength is half of the framelength. if 75% overlap the hoplength is a quarter framelength. for that 32 or 64 sample real-time live thingie, i would call those "blocks" or maybe "chunks" of samples and call the 32 or 64 samples the "blocklength". $\endgroup$ Jan 1 at 18:00
  • $\begingroup$ So blocklength is the better term? $\endgroup$
    – neolith
    Jan 1 at 19:49
  • $\begingroup$ @Hilmar: I have never used DMA and vectorized instructions before. When I have a DSP that can easily handle sample-by-sample processing, would it not be better to do so? $\endgroup$
    – neolith
    Jan 1 at 19:55
  • $\begingroup$ If you have more MIPS than you need, that's perfectly fine. $\endgroup$
    – Hilmar
    Jan 1 at 23:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.