trevormarvinlab
New member
I've been using the audio library for some interesting non-audio things. In one of the processes I've written, I've had a need to flush an FFT of all data and start putting new and different data in it. I'd first tried to dynamically delete and allocate new instances when I needed to restart the FFT. The compiler gave be a pretty big warning about this, something about the destructor being or not being a "virtual method", and indeed there were issues. This caused a memory leak of available audio blocks, eventually exhausting my supply of them and hanging the program.
I modified the FFT1024 code on my machine to include the method shown below. With this, I was able to "flush" the audio blocks out before I deleted the instance and (appear to) not have a memory leak. (Still trying to fully verify this.) I eventually found that it seems that this "flush" approach worked for my need to reset the state of the FFT and purge all previous data, and thus moved to not dynamically allocating FFT instances.
This seems to work, but I'm not fully sure of it. Review by someone who has a better grasp of this code would be appreciated. If this does work, I suggest adding it as a method to both FFT libraries, and call it in the class destructor to ease this memory leak issue for others who may be dynamically creating these.
And to get cute with extra compact code...
I modified the FFT1024 code on my machine to include the method shown below. With this, I was able to "flush" the audio blocks out before I deleted the instance and (appear to) not have a memory leak. (Still trying to fully verify this.) I eventually found that it seems that this "flush" approach worked for my need to reset the state of the FFT and purge all previous data, and thus moved to not dynamically allocating FFT instances.
Code:
void flush() {
for (uint8_t i = 0; i < state; i++) {
release(blocklist[i]);
}
state = 0;
}
This seems to work, but I'm not fully sure of it. Review by someone who has a better grasp of this code would be appreciated. If this does work, I suggest adding it as a method to both FFT libraries, and call it in the class destructor to ease this memory leak issue for others who may be dynamically creating these.
And to get cute with extra compact code...
Code:
void flush() {
while (state) release(blocklist[--state]);
}
Last edited: