Oh, good, I think we’re on the same page then! (Thanks for the chance to chat on this, I really appreciate it…)
I don’t directly have my big cache being read on the same thread that actually fills audio stream, in other words, it’s NOT being read as part of the call to getNextAudioBlock() from the AudioDeviceManager. I have my own buffered audio source (I don’t love the JUCE one, sorry Jules, mine’s smaller and doesn’t contain its own thread) that seems to work.
OK. So I think we are all in agreement that if I either read disk or hit my large buffer on the audio thread then I’ll have issues.
What I’m doing is somewhat different. I have the huge cache, which I expect on small machines to be paged out most of the time. It’s still to my advantage, because I don’t have to keep reading the CD while the user is looping on it, which is noisy on small machines and laptops, and physically wears the drive out, even (and CD seeks are wicked slow…)
There are three threads here. The fetch thread copies the data to the huge cache from the original source: hard disk, CD or even a URL. The buffering thread processes samples from that cache, and puts it into my small circular real-time buffer. The audio thread, which is run by Juce and not me, copies data from the small real-time cache into
So I’m expecting that huge cache to regularly be paging in big chunks of the audio from swap, and blocking for a few ms when it does. That’s fine.
But I can do that, and my audio thread should continue to run smoothly, even on a small machine… or, is there a reason not?
Again, I’m not seeing the slightest issue at all - but it’s going to be weeks before I get to really test it on a variety of machines, wanna avoid bad surprises…