Which thread calls audioDeviceAboutToStart, ...Stopped?

General JUCE discussion
1

AudioIODeviceCallback::audioDeviceAboutToStart (AudioIODevice* device) AudioIODeviceCallback::audioDeviceStopped ()

Does Juce specify which threads these will be called on? And if not, can we get some assurances?

Client code that wants to use the “device” parameter from audioDeviceAboutToStart may be simplified if Juce can guarantee that audioDeviceAboutToStart only gets called from the thread which is calling into the AudioDeviceManager (the documentation is silent on this topic).

1 Like
2

No, I don’t think I can give any guarantees about that - there are too many possible platforms and device peculiarities to deal with. None of the calls to any of the AudioIODeviceCallback methods will overlap each other, but they could happen on any thread.

3

The issue is that when I create new audio objects after a device has been started, I need to call prepareToPlay() with appropriate parameters for buffer size and sample rate. These come from the AudioIODevice pointer. Ideally, I would like to prepare these new audio objects outside of the callback so the burden of construction and initialization does not fall on the hardware thread.

Can I assume that the only way for an AudioIODevice pointers to become invalid is through invoking a member of AudioDeviceManager? If that is the case then I can protect the entire AudioDeviceManager with a critical section.

4

hmm… probably not 100% safe - e.g. a device could stop working if it gets unplugged or something.

5

hmm… probably not 100% safe - e.g. a device could stop working if it gets unplugged or something.[/quote]

How do you suggest I call prepareToPlay with the right parameters, from outside the audio callback?

6

I’d suggest doing it in audioDeviceAboutToStart - the whole point of the method is that it’s where you can set-up your stuff. I can’t guarantee the thread that will call it, but I would say that it’s ok to spend some time doing work in there.

7

Yes of course, but I’m talking about audio components that are created AFTER the initial call to audioDeviceAboutToStart. For example, the user adds a new PositionableAudioSource into their AudioProcessorGraph.

Just an example. I’m not using the audio graph stuff. In my case I have to manually call prepareToPlay() with the “current” buffer size and sample rate. These values come from the device pointer.

8

Well, personally I’d probably use a CallbackMessage or something to do it on the message thread.