Bug in ResamplingAudioSource?


Lately i’ve been busy building an audio clip player / looper thingy.
I’ve created my own audiosource for doing the looping, and I’m using a ResamplingAudioSource to control the pitch of the loop.
As logic dictates I’ve constructed the ResamplingAudioSource with the looperSource as input source.
What then happens is this: when I start freaking out on the pitch slider the application will crash from time to time, causing a BAD_ACCESS in the audioReader i’m using to read the file. The cause of this seems to be a NEGATIVE startSample in the const AudioSourceChannelInfo& info struct that I recieve from the ResamplingAudioSource.
I know from working with DSP filters that changing a parameter really fast can lead to some unpredictable results…or am I just missing something completely obvious here?


I guess there could be overflow/numeric problems if you use really extreme numbers - I’ve only ever tested it with “sensible” resampling ratios.


Sensible as in ratio’s like 0.5, 2, 4? I’ve tried limiting the slider range to [0.0001 - 10] and it still crashes, but it doesn’t seem to happen if i move the slider slowly…
Could it have something to do with the fact that a call to the loopers getNextReadPosition() returns the read position in the loop, not the total amounts of samples played so far (nextPlayPos = [loopStart, loopEnd])?


Oh, I just took a look and it wasn’t actually thread-safe, so changing the ratio while it’s playing would certainly have messd it up. Try the version I’ve just checked-in now…


Thanks for the quick response! Altough it seems (yes, seems) a bit more stable, it still happens sometimes. When I link in libjucedebug.a and run in debug mode, I can see a jassert triggered in ResamplingAudioSource.cpp on line 155: jassert (sampsInbuffer > 0) .


Well that’s all nicely locked now, so it won’t be a concurrency problem. Limits like 0.0001 do seem pretty edgy though - does it ever happen if you stick to a range like 0.1 to 10?


Yep, still happens…


Strange… Let me know if you spot any clues.


Although I really don’t understand the dsp engine of the ResamplingAudioSource, I’ve come across a snippet of code that I think could be responsible for the problem (in ResamplingAudioSource.cpp, starting at line 155):

jassert (sampsInBuffer > 0);

while (subSampleOffset >= 1.0)
if (++bufferPos >= bufferSize)
bufferPos = 0;

 nextPos = (bufferPos + 1) % bufferSize;
 subSampleOffset -= 1.0;


If sampsInBuffer will become negative, it will allow readInfo.startSample to be negative as well (wich is copied from endOfBufferPos = bufferPos + sampsInBuffer (line 107 & 119))
Isn’t limiting sampsInBuffer to 0…whatever not the solution?


True, that value shouldn’t be allowed to become negative. If you tweak it, does that fix your problem?