JUCE full-duplex audio example project?

1

Hi,
Apologies if I’ve missed the obvious. I’ve tried compiling and running the various audio examples provided with Projucer. But one key example appears to be missing; audio callback in/out with a FIFO to/from a separate audio processing thread (or even a thread pool). (This is one of the more challenging things to set up in terms of FIFO’s that work across threads.) Is there a sample project anywhere else? I have something working in QT but it’s not very efficient, and I’d love to see how JUCE does it.
Thanks,
Michael

2

This is basically represented in the design of the AudioProcessor and AudioProcessorEditor classes and you can dig into the JUCE code itself to see how it handles audio processing. I think all the plumbing of setting up the Audio I/O callbacks is pretty well abstracted in the AudioProcessor classes … definitely worth reading.

3

In general, this functionality should be handled transparently. For example, when using CoreAudio on macOS with separate input and output devices, each device has a separate IO thread, but JUCE will use the input device’s thread for the bulk of the processing (including calling the user’s audioDeviceIOCallbackWithContext), and will use a FIFO to push outgoing data onto the output device’s thread.

If you’re interested in how this all works, you could take a look in juce_mac_CoreAudio.cpp. In practice, you shouldn’t need to rewrite any of this multi-threaded I/O unless you’re doing something quite specialised, such as spawning your own additional realtime threads.

4

Thanks very much.

… but JUCE will use the input device’s thread for the bulk of the processing…

So is JUCE processing audio in the soundcard audo callback or in a thread separate from the soundcard callback?

Edit: Having debugged through some of the demo apps, it appears that all audio processing is being called from the soundcard callback. Years ago I was taught that thisis a huge no-no, and that the soundcard callback needs to be returned as quickly as possible, so as not to hold up other things the soundcard needs to do. Apparently that philosophy has changed.

And yes, I am interested in spawning my own additional realtime threads to spread processing load. I have a “soundcard callback <-ring buffer-> separate processing thread ↔ processing thread pool” setup running in QT, but the QT GUI side of things doesn’t look as clean as JUCE and I’m interested in moving over to JUCE.