Audiothumbnail and thread safety

General JUCE discussion
1

Hi -

I’ve been experimenting with the juce QTAudioFormat that allows MP3 decoding.

Since the decoder is rather slow, I load the file in a background worker thread so that I can keep the program UI and other functions moving along and start playing the file immediately.

I also took a look at the audioThumbnail class … awesome. I love that I can just start it with a few simple commands and it will create the thumbnail in (another) background thread.

Thread safety? … ohhhh, you see where this is going. Two background threads trying to access the same resource can be bad news … and is at least with MP3’s.

I’m pretty familiar with thread safety issues, but am not sure how the audiothumbnail class works exactly … or if I have access to that thread? I tried creating a criticalSection object … but since I have no way to tell the audiothumbnail thread to use it, I’m at a loss.

Is there a way to lock a resource in juce … as in lock(file) … so that only one thread will access a file, or buffer, etc. … at a time? Or can I sync the audiothumbnail thread … use threadpool or timeslice to only trigger the thread as the file reader thread exits, and vice versa … ?

I feel there is an easy answer here and I just haven’t found it in the source tree yet (juce seems to have built in solutions for every problem when I look long enough).

Anyway, any help is appreciated.

Thanks
Aaron

2

You’d really need two different reader objects for this to work.

Even if a reader was thread-safe, you couldn’t let two things read it at the same time - it’d be jumping about and rebuffering so much that the performance would be vastly slower than just using two separate streams.

3

Hmmm … I kinda thought I already had two separate reader objects … or at least two separate streams. Here’s what I’m doing …

… instantiate the thumb

audioThumb = new AudioThumbnail(256, *AudioFormatManager::getInstance(), *audioThumbCache);

… then after the load button is clicked …

// first, create this reader …
reader = AudioFormatManager::getInstance()->createReaderFor(*fileToLoad);

// now with the same file … an audiothumbnail object
audioThumb->setSource(new FileInputSource (*fileToLoad));

… so there are two readers here … both off the same AudioFormatManager instance … right? Or does the manager see the same file path and try to use just one reader ?