I use some buttons to activate and de-active some features. But i noticed a strange behavior. When i click on the button it adds a clicking or a small bursting sound . Is there anyone else who came across to such an issue?
At first, i thought it is because of the switching between buffers. I tried to apply a ramp but still it is happening.
Is it possible that the “buttonClicked” creates an interrupt and cause such a problem ? or should i try to apply more ramp or cross-fading.?
How does your buttonClicked callback function interact with the processing? You should have in mind that the button callback will come from the message thread while your processing is handled from another thread. If both threads are working on the same data in the moment you click the button, all nasty kind of artifacts and undefined states can occur…
and no, a button click does not create an interrupt. The issue will be in your code. @PluginPenguin is pointing in the right direction, ie. how does the action of your button interact with the code in your audio thread?
For example, i created a circular buffer to store a part of the input samples. It stores it but after storing and then trying to play it, it adds a bursting sound somewhere in the buffer. I tried to increase the buffer size, use a constant time to store, apply the fadein-fadeout-ramp,… nothing helped. I thought maybe it is because something else. I thought maybe there is an interrupt or something else that causes this issue.
Here is my code :
It has been more than a month but still i couldn’t find a way to get rid of it.
I can’t find any code from your button callback with a quick scan over the thread you’ve linked and the code snippets found there. To clarify it: Do your button callbacks you are suspecting to be the cause interact with the processing in any way? If so my assumption was that the stuff you perform inside your buttonClicked function could be the cause of the artifacts you hear, but that’s just a guess since I don’t know what you do on button clicks
And one more thing, as you are speaking of “Interrupts”. Do you have a microcontroller background and do you mean real hardware interrupts like the ones used in microcontrollers to handle e.g. button presses? If so, no, software on a computer with an operating system works completely different, to handle concurrent stuff, multithreading is used with multiple threads probaly really running two pieces of code at the same time on a multicore CPU (and this links back to my assumption from above that your implementation lacks thread safety in some way)
sorry i just noticed that.I was just trying to show you the way i record and play it.
In my buttonclicked method i just toggle a flag. 0 or 1. That’s it. In my process block i do something like this
void FreezeAudioProcessor::processBlock (AudioBuffer< float >& buffer, MidiBuffer& midiMessages)
const int totalNumInputChannels = getTotalNumInputChannels();
const int totalNumOutputChannels = getTotalNumOutputChannels();
for ( int i = totalNumInputChannels; i < totalNumOutputChannels; ++i)
buffer.clear (i, 0, buffer.getNumSamples());
for (int channel = 0; channel<totalNumInputChannels; ++channel)
const float* bufferData = buffer.getReadPointer (channel);
const float* freezeBufferData = mFreezeBuffer.getReadPointer (channel);
// copy the data from main buffer
// fill it back with freezebuffer
// when i uncomment getFromFreezeBuffer i get a bad access memory error.
mWritePos += bufferLength;// to move to next 512 samples
mWritePos %= freezeBufferLength ;// to go back to the beginning