Multithreaded Audio Playback and Recording


#1

In JuceDemo project, for audio demo, there is a tab for playback and another tab for recording. If I want to do the playback and recording at the same time, each runs within its own thread, how to do that? Can I use two AudioDeviceManager instances, one for the playback, and the other for the recording?
Here is the code piece I can think of:

    AudioDeviceManager dm1;
    AudioDeviceManager dm2;
    dm1.initialise (2, 0, 0, true, String::empty, 0); // for recording
    dm2.initialise (0, 2, 0, true, String::empty, 0); // for playback
    // start thread 1 and do the following
    dm1.addAudioCallback (&audioRecorder);
    // start thread 2 and do the following
    dm2.addAudioCallback (&audioSourcePlayer);

Will it work? Or there is a better way to implement it than the above hack?

Thanks.


#2

You should probably just have one AudioDeviceManager. It can have more than one callback so just add them both.

    AudioDeviceManager dm1;
    dm1.initialise (2, 2, 0, true, String::empty, 0); // for recording
    dm1.addAudioCallback (&audioRecorder);
    dm1.addAudioCallback (&audioSourcePlayer);

#3

If both callbacks are added to the same AudioDeviceManager, wouldn’t it be single threaded? The AudioDeviceManager will call each callback one by one within its thread?

[quote=“Graeme”]You should probably just have one AudioDeviceManager. It can have more than one callback so just add them both.

AudioDeviceManager dm1; dm1.initialise (2, 2, 0, true, String::empty, 0); // for recording dm1.addAudioCallback (&audioRecorder); dm1.addAudioCallback (&audioSourcePlayer); [/quote]


#4

You can’t do audio i/o on two separate threads because it is the operating system that provides the thread for your callback. This is how it works on the majority of operating systems, and the model used with JUCE.


#5

[quote=“AlexY”]If both callbacks are added to the same AudioDeviceManager, wouldn’t it be single threaded? The AudioDeviceManager will call each callback one by one within its thread?
[/quote]

Besides all the other said, audio I/O uses buffers, is not real time. Therefore you shouldn’t have to worry about multithreading.


#6

That’s exactly right. So you need to the least possible work inside the callback. It’s common to have another thread, such as the juce bufferingaudiosource uses to do disk access and longer work, then, in the callback, just take or give pre-prepared audio samples.

Bruce


#7

Thanks for all the responses. Looks like I have to find a way to make it multithreaded even though there is only one AudioDeviceManager thread.


#8

I don’t understand why you’re asking this question in the first place… If you have two audio callbacks, why would it cause problems for you if they were called from the same thread?

Do you understand that a callback has to be super-fast, and you can’t do any file access, or anything that might block in there? If you want it in parallel because you’re planning on spending more than 50% of the CPU time in each callback, then your entire design is screwed anyway!