Would a lock due to allocation of memory cause sample data to be affected?

Hi All,

Really struggling with an issue, my plugin keeps “clicking”. I’ve gone over my dsp code and I am fairly sure it can’t be anything within that - I completely reengineered it up from the ground initially to try and solve the problem but nothing… I do however allocate some AudioBuffers in the process block (yes, I know I shouldn’t do this and I will get rid of them). But, I’m interested to know if this would in anyway cause some clicks? I understand if it would cause clicks on output (realtime audio waits for no man) but when I record the plugin from another track within the daw the click is present still… Would it be making up sample data or just using junk that hasn’t yet been allocated yet etc? Thanks to anyone that can weigh in!

1 Like

Testing with an offline render would be a better test than recording to another track. If in that case you still get clicks, there’s probably some problem in the way you are accessing/calculating the samples, and not an issue with the memory allocations.

Maybe you are accessing some samples from the buffers that you shouldn’t be? Are you clearing the buffers after you’ve created them? As an optimization, AudioBuffer’s constructor doesn’t set the samples to zero so you need to do it yourself if it’s important that the buffers start as completely silent.

In any case, you should get rid of the AudioBuffer allocations in the processBlock as soon as possible. Is there some complication why you haven’t done that already?

Are you assuming the size of the buffer from the host is always the same? You should not do that, you have to be prepared to deal with buffers of varying size for each processBlock call.


Thanks, I’ll try that out.

I am 99.99% sure I’m not, I’ve checked and double checked if this is possible to do within my code. Wouldn’t it cause a jassert anyway?

No, I assumed as I’m replacing all the sample data anyway this wouldn’t be an issue?

I don’t really have a good reason, I’m creating them in processBlock as a lazy way of dealing with varying size buffers.

Thanks for your help.