Dropped audio buffers in AU Synth plugin

Audio Plugins
1

Before I start going through my project with a fine toothcomb I wondered if anyone might recognise my problem and suggest where to start looking for what’s causing it?

Basically, I very occasionally get a dropped buffer (well it looks like one early or late buffer followed by a completely empty one) image here:

http://164.11.131.73/svn/CEMS/mt/msc/gp/trunk/notes/dropbufferbug.jpg

It usually does it when creating lots of synth events but it does happen before voices are used up (i.e. before voice stealing occurs) and even with 128 voices the CPU is only averaging 50% in AU Lab. I suspect it only seems to fail when there are lots of events due to the increased probability but I may be wrong.

I’m fairly sure it’s not happening in the wrapper ProcessBufferLists when the

if (juceFilter->isSuspended())
{
...

check, zeros the buffer.

The whole project is at: (browsable or SVN checkout)
http://164.11.131.73/svn/CEMS/mt/msc/gp/trunk/

…but it’s quite big (135MB if you checkout the whole trunk) as there are some currently unused audio samples in there as that’s the eventual plan once these dropouts are sorted!

As a long shot I tried zamrate’s Mac Timer class mod but nope…[/code][/img]

2

That’s pretty strange, I can’t think how the plugin could mix up buffers like that, it sounds more like the host that’d be messing up.

I guess that even if average cpu is only at 50%, a spike in the cpu caused by something else could make one buffer take too long, causing the host to panic and drop the next one before getting back into its stride.

3

I found a way to make it reliably bad!

I’ve been testing it up to now using the MidiKeyboardComponent (pretty much left in from the Juce demo plugin). It rarely glitches using the MidiKeyboardComponent to trigger sounds but ALWAYS glitches in time (immediately following) any MIDI note event (on or off).

4

Sounds like a thread-locking issue - if the midi messages are delivered on a different thread to the audio thread, that could be blocking the audio thread, I guess.

5

Nope… it was even more dumb than that.

void MySynthVoice::renderNextBlock(AudioSampleBuffer& outputBuffer, int startSample, int numSamples)
{
...	
		for(int sampleIndex = 0; sampleIndex < numSamples; sampleIndex++) 

...

… then I was using sampleIndex as the index into the buffer instead of startSample+sampleIndex