BufferingAudioSource – how is it useful?

Hi,

I have been playing around with JUCE, building a simple audio file player. I was getting audio glitches, so I ran it through a profiler and noticed that the culprit was `BufferingAudioSource`. It seems like when it runs it time slice to prefetch audio from its source, it uses a lock which makes the audio thread wait for it.

Isn’t this a textbook example of priority inversion? Or am I just misunderstanding how `BufferingAudioSource` is supposed to be used?

Erik

It would be easier to understand what the problem is, if you showed some code.

edit : the intention of the BufferingAudioSource is to smooth out occasional I/O timing spikes of the AudioSource it is using. You should probably make it use a pretty long buffer for it to be useful, like in the hundreds of milliseconds range. The underlying AudioSource should also still make the best attempt to run as fast as possible. If your original AudioSource is not fast enough, the realtime audio thread will quickly consume the prebuffered audio and you will get a glitch. You may also want try to tweak the priority of your TimeSliceThread.

Thanks for your answer!

My problem isn’t mainly the practical issue, but the principal question: there are so much written about real-time constraints and that one shouldn’t use locks in the audio thread. Yet, this JUCE class uses a mutex which blocks the audio thread. This made me curious.

Interestingly, using a (very) longer buffer makes the problem worse, since that increases the time it takes to fill the buffer, leading to longer waits on the lock. Of course I could tweak the buffer size, thread priority and so on, and while that may solve the problem for many practical applications, the basic problem still exists: the reader thread blocks the real-time thread while reading.

Unless there is something I misunderstood? I would be happy to be wrong!

Most if not all of juce audio classes involved with audio and midi devices management, audio plugins, audio processors, audio sources they are locking in the realtime thread for one reason or another.