Initializing AudioDeviceManager crashes or screws up Digital Performer

General JUCE discussion
1

JUCE 8.0.4, MacOS, Big Sur, Digital Performer 11

I’m working on a standalone GUI App, that has plugin hosting capabilities. As such, I need to specify Audio Settings.

What is the right way to initialize an AudioDeviceManager or load settings without screwing up other Audio apps that are open?

When I launch my app, it cause DigitalPerformer to either report (in the best case), or in some cases to crash, or shut off MAS, i.e.:

motu1
motu1843×363 28 KB

motu2
motu2550×613 59.2 KB

I’m just doing this on startup, essentially:

    auto savedState = getAppProperties().getUserSettings()->getXmlValue ("audioDeviceState");
    String s = getDeviceManager().initialise (0, 256, savedState.get(), true);

If I comment it out, then nothing happens to Digital Performer when I launch my app.

I’m writing the AudioDevice settings to my Properties file,

My Properties xml contains:

<VALUE name="audioDeviceState">
    <DEVICESETUP deviceType="CoreAudio" audioOutputDeviceName="Multi-Output Device"
                 audioInputDeviceName="Jump Desktop Audio" audioDeviceRate="48000.0"
                 audioDeviceInChans="11" audioDeviceOutChans="11"/>
  </VALUE>
2

Does Digital Performer cope if you change the audio settings from other programs, Audio MIDI Setup, REAPER, Logic etc? This may be an issue with Digital Performer itself, rather than something you can work around.

3

hi @reuk - upon further investigation, this appears to be caused by trying to change the sample rate to 48k, when Digital Performer is open with a 96k projects and the computer is attached to my MOTU 896 mkIII audio interface, which is set to 96k.

It happens with the AudioPluginHost as well, so it’s indeed a DP issue.

But I wonder is there some way to query the current sample rate (before initializing the AudioDeviceManager) and not change it if it’s in use by somebody else, or something…?

4

I’ve seen other issues with instantiating an app that uses a device that is already in use by another app/host, such as the sample rate changing underneath you in that other app/host. You can, for instance, attach to an audio device in a host, have it running, then go to the system settings for that device and change its sample rate. That will break the running app. In DPs case, they detect that and throw the error. In other cases, you might just suddenly be playing back at the wrong sample rate. (That’s what happens with the app I’m working on now.)

1 Like
5

Yeah, upon further reflection I’ve decided I’m over-thinking this. If the user wants to change the sample rate while another app is open, or launches your app with a saved sample rate that is different from another app that is currently running, then the user must deal with the ramifications.