audio lib generates more cpu overhead over time

pix-os

Well-known member
i am having a weird issue regarding the audio library.

namely that the cpu load increases over time.

cpu load start: 75.25%
after 2 minutes of slow climbing: 80.45%
after 5 minutes it has climbed up to 80.87%
after 10 minutes it is 81.22%
(values are peak)

this is a teensy 3.6 with 6 reverb instances, some filters, side encoders and mixers at 144mhz, smallest code
the dsp's ram usage stays the same, so i doubt it's a memory leak.

teensyduino 1.36, arduino 1.8.1 (win 8.1 x64)

i have a delay and serial.print routine in my loop, and just some patch init stuff at setup

code below:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioInputI2S            i2s1;           //xy=55,222
AudioFilterStateVariable filter3;        //xy=213,405
AudioFilterStateVariable filter4;        //xy=217,109
AudioEffectMidSide       midside2;       //xy=359,246
AudioEffectReverb        reverb1;        //xy=365,75
AudioEffectReverb        reverb6;        //xy=367,362
AudioEffectReverb        reverb2;        //xy=376,194
AudioEffectReverb        reverb4;        //xy=376,426
AudioEffectReverb        reverb3;        //xy=379,296
AudioEffectReverb        reverb5;        //xy=386,136
AudioMixer4              mixer2;         //xy=591,288
AudioMixer4              mixer1;         //xy=596,198
AudioEffectMidSide       midside1;       //xy=687,46
AudioEffectMidSide       midside3;       //xy=713,397
AudioFilterStateVariable filter1;        //xy=730,158
AudioFilterStateVariable filter2;        //xy=745,225
AudioOutputI2S           i2s2;           //xy=775,342
AudioMixer4              mixer4;         //xy=882,245
AudioMixer4              mixer3;         //xy=915,128
AudioConnection          patchCord1(i2s1, 0, mixer3, 0);
AudioConnection          patchCord2(i2s1, 0, filter4, 0);
AudioConnection          patchCord3(i2s1, 1, mixer4, 0);
AudioConnection          patchCord4(i2s1, 1, filter3, 0);
AudioConnection          patchCord5(filter3, 2, reverb4, 0);
AudioConnection          patchCord6(filter3, 2, midside2, 1);
AudioConnection          patchCord7(filter4, 2, reverb1, 0);
AudioConnection          patchCord8(filter4, 2, midside2, 0);
AudioConnection          patchCord9(midside2, 0, reverb2, 0);
AudioConnection          patchCord10(midside2, 0, reverb6, 0);
AudioConnection          patchCord11(midside2, 1, reverb3, 0);
AudioConnection          patchCord12(midside2, 1, reverb5, 0);
AudioConnection          patchCord13(reverb1, 0, mixer1, 3);
AudioConnection          patchCord14(reverb6, 0, mixer2, 0);
AudioConnection          patchCord15(reverb2, 0, mixer2, 2);
AudioConnection          patchCord16(reverb2, 0, mixer1, 2);
AudioConnection          patchCord17(reverb4, 0, mixer2, 3);
AudioConnection          patchCord18(reverb3, 0, mixer2, 1);
AudioConnection          patchCord19(reverb3, 0, mixer1, 1);
AudioConnection          patchCord20(reverb5, 0, mixer1, 0);
AudioConnection          patchCord21(mixer2, 0, filter2, 0);
AudioConnection          patchCord22(mixer2, 0, mixer4, 2);
AudioConnection          patchCord23(mixer1, 0, filter1, 0);
AudioConnection          patchCord24(mixer1, 0, mixer3, 2);
AudioConnection          patchCord25(midside1, 1, mixer3, 3);
AudioConnection          patchCord26(midside3, 1, mixer4, 3);
AudioConnection          patchCord27(filter1, 0, mixer3, 1);
AudioConnection          patchCord28(filter1, 1, midside1, 1);
AudioConnection          patchCord29(filter1, 1, midside3, 1);
AudioConnection          patchCord30(filter2, 0, mixer4, 1);
AudioConnection          patchCord31(filter2, 1, midside1, 0);
AudioConnection          patchCord32(filter2, 1, midside3, 0);
AudioConnection          patchCord33(mixer4, 0, i2s2, 1);
AudioConnection          patchCord34(mixer3, 0, i2s2, 0);
AudioControlSGTL5000     sgtl5000_1;     //xy=653,456
// GUItool: end automatically generated code

const int myInput = AUDIO_INPUT_LINEIN;


void setup() {
  AudioMemory(30);
  SPI.setSCK(14);
  SPI.setMOSI(7);
  sgtl5000_1.enable();
  sgtl5000_1.volume(0);
  sgtl5000_1.inputSelect(myInput);
  sgtl5000_1.micGain(0);
  sgtl5000_1.lineInLevel(0);
  sgtl5000_1.adcHighPassFilterDisable();
  delay(500);

  
  reverb1.reverbTime(10);
  reverb2.reverbTime(7);
  reverb3.reverbTime(7);
  reverb4.reverbTime(10);
  reverb5.reverbTime(7);
  reverb6.reverbTime(7);

  filter1.frequency(8000);
  filter2.frequency(8000);
  filter1.resonance(0.5);
  filter2.resonance(0.5);

  filter3.frequency(2000);
  filter4.frequency(2000);
  filter3.resonance(0.7);
  filter4.resonance(0.7);
  
  midside1.encode();
  midside2.encode();
  midside3.encode();

  mixer1.gain(0,0.2);
  mixer1.gain(1,0.4);
  mixer1.gain(2,0.3);
  mixer1.gain(3,0.8);
  
  mixer2.gain(0,0.2);
  mixer2.gain(1,0.4); //wide reverb
  mixer2.gain(2,0.3); //mid reverb
  mixer2.gain(3,0.8); //normal reverb


  mixer3.gain(0,0.7); //dry
  mixer3.gain(1,0.9);
  mixer3.gain(2,0.5);
  mixer3.gain(3,0.5);
  mixer4.gain(0,0.7); //dry
  mixer4.gain(1,0.9);
  mixer4.gain(2,0.5);
  mixer4.gain(3,0.5);
  
  Serial.begin(115200);
  
  sgtl5000_1.volume(0.8);
}

void loop() {
  // put your main code here, to run repeatedly:
  delay(500);
  Serial.print("CPU USE: ");
  Serial.print(AudioProcessorUsage());
  Serial.print(",");
  Serial.print(AudioProcessorUsageMax());
  Serial.print("    ");
  Serial.print("RAM: ");
  Serial.print(AudioMemoryUsage());
  Serial.print(",");
  Serial.println(AudioMemoryUsageMax());

}
 
You seem to have a lot of memory requirements because of the high number of audio lib objects.

Try a higher number of reserved audio blocks:
AudioMemory(60);

I experience exactly the same phenomenon in my Teensy Convolution SDR when doing a high number of real time calculations while the audio queue backs up the audio data.
It also helps to empty the audio queue from while to while in my case . . . I have set AudioMemory(100); because of the high number of blocks I need in one audio queue.

HTH,

Frank
 
i don't think so, as the audio memory peak usage is only 17 blocks, with 8 average, so not close to the 30 block i have given it.

anyhow, will give it a chance

edit: still having the same issue with 60 audio ram blocks (max i tried is 80 blocks (limited by mcu ram), same effect). (measured a timespan of 2 minutes each time)

edit 2: i opened an issue on github as well, as i find it fitting more to github than the forum (https://github.com/PaulStoffregen/Audio/issues/224)
 
Last edited:
hm. first, it's the nature of a peak-value that it increases over time where there a new, higher peaks.
But that does not mean there's no bug.
a) can you measure it over a longer period (1 hour) - does it still rise ?
b) please try to identfy the audio-object that causes the rising cpu load (remove parts from your code..)
 
Last edited:
hi frank, i will test it for an hour right now, and i never had it with audio projects before the reverb was added in, so it might be that's the issue, i just am not sure yet.

anyhow, starting test now with core clock at 120mhz, will respond back soon :)

edit: why i suspect the reverb to be the issue:

i have the same issue with this simple code:

Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioInputI2S            i2s1;           //xy=237,275
AudioEffectReverb        reverb1;        //xy=374,220
AudioEffectReverb        reverb2;        //xy=377,348
AudioMixer4              mixer1;         //xy=526,248
AudioMixer4              mixer2;         //xy=527,331
AudioOutputI2S           i2s2;           //xy=722,349
AudioConnection          patchCord1(i2s1, 0, reverb1, 0);
AudioConnection          patchCord2(i2s1, 0, mixer1, 0);
AudioConnection          patchCord3(i2s1, 1, reverb2, 0);
AudioConnection          patchCord4(i2s1, 1, mixer2, 0);
AudioConnection          patchCord5(reverb1, 0, mixer1, 1);
AudioConnection          patchCord6(reverb2, 0, mixer2, 1);
AudioConnection          patchCord7(mixer1, 0, i2s2, 0);
AudioConnection          patchCord8(mixer2, 0, i2s2, 1);
AudioControlSGTL5000     sgtl5000_1;     //xy=318,401
// GUItool: end automatically generated code



#define myInput AUDIO_INPUT_LINEIN

void setup() {
  // put your setup code here, to run once:
  AudioMemory(30);
  SPI.setSCK(14);
  SPI.setMOSI(7);
  sgtl5000_1.enable();
  sgtl5000_1.volume(0);
  sgtl5000_1.inputSelect(myInput);
  sgtl5000_1.micGain(0);
  sgtl5000_1.lineInLevel(0);
  sgtl5000_1.adcHighPassFilterDisable();
  delay(500);

  
  reverb1.reverbTime(10);
  reverb2.reverbTime(10);

  mixer1.gain(0,0.6);
  mixer1.gain(0,0.6);
  
  mixer2.gain(0,0.6);
  mixer2.gain(0,0.6);
  
  sgtl5000_1.volume(0.8);
  Serial.begin(115200); 
}

void loop() {
  // put your main code here, to run repeatedly:
  delay(500);
  Serial.print("CPU USE: ");
  Serial.print(AudioProcessorUsage());
  Serial.print(",");
  Serial.print(AudioProcessorUsageMax());
  Serial.print("    ");
  Serial.print("RAM: ");
  Serial.print(AudioMemoryUsage());
  Serial.print(",");
  Serial.println(AudioMemoryUsageMax());

}

edit 2:

also, the average values of the dsp load go up slowly as well, so it's not only the peak value.
 
Last edited:
notes: cpu loads are rounded to 1 decimal.

start test (peaks: 85.2% cpu, 20 blocks ram)
5 min measurement (peaks: 88.0% cpu, 20 blocks ram)
10 min measurement (peaks: 88.5% cpu, 20 blocks ram)
15 min measurement (peaks: 89.0% cpu, 20 blocks ram)
20 min measurement (peaks: 89.0% cpu, 20 blocks ram)
<forgot to monitor at 25 min>
30 min measurement (peaks: 91.2% cpu, 20 blocks ram)
35 min measurement (peaks: 91.3% cpu, 20 blocks ram)
40 min measurement (peaks: 91.3% cpu, 20 blocks ram)
45 min measurement (peaks: 91.3% cpu, 20 blocks ram)
50 min measurement (peaks: 91.3% cpu, 20 blocks ram)
55 min measurement (peaks: 91.3% cpu, 20 blocks ram)
60 min measurement (peaks: 91.3% cpu, 20 blocks ram)

what i noticed:
the cpu usage is rising in a log scale and becomes stable after 40 minutes.
can it be the case of the mcu's rising temperature over time (as i did the test from a cold start at 18 degrees C)?

IF this is the issue, i'd suggest leaving 10% of the DSP load free to stay on the safe side and avoid buffer underruns to happen after a while.

small update, i re opened the serial monitor and found out it gas gone up to 91.5%
 
Last edited:
The temperature has no influence.
Hm, not sure if the that little rising (from 85.2 -> 91-5) is a bug. I guess it's just normal and no bug is involved. The measuring includes the time for handling interrupts.
There are some interrupts used (systick, usb... and others) , and every time an interrupt is called, the usage will be a bit higher. There might be cases where several interrupts are called during an audio-block.
Of course this happens more likely the longer the sketch is running and you see a rising peak value.
 
Last edited:
the one thing i find weird about it is that the usage stays high and never goes down again
even average usage stays high, but still varies a bit, but never gets close to the start value again.
 
Hm, I thought you were referring to the peak-value only. I've missed that the average rises, too.
 
the average at start was around 84% and now remains over 90%

small update, after 1 hour and 45 minutes have passed, the average cpu is about: 91.2% and the peak usage is 91.63%

enough updates for now about the usages, it's clear to me that there's a bug somehwere.
 
Last edited:
Back
Top