Two questions about either building a new Component or expanding the functionality of the original:
[1] Is it possible to configure the settings without changing the current device? I’m thinking OK / Apply / Cancel here. Specifically, is it possible to switch between devices or device types, and have the list channel assignments and attributes (sample rate, buffer size) change, without changing current playback?
[2] Is it possible for the Component to be dynamically notified of changes to the underlying hardware? For example, if I bring up the ASIO external interface (or the Fireface Settings applet) and change something like sample rate or buffer size, can the Component get notified? I’ve seen this happen in other programs so in theory it is possible. Perhaps only with ASIO though. I do notice that when I change settings externally and then change something in the AudioDeviceSelectorComponent, it usually discovers the change (because it rebuilds the controls from the device settings every time an item is changed?)
Any insights into the limitations and possibilities of this Component would be appreciated, I’m close to having to implement my own version of it.
I second this question. More specifically, an AudioDeviceSelectorComponent is linked to an AudioDeviceManager.
The doc of AudioDeviceManager states :
[quote]The idea is that your application will create one global instance of this object, and let it take care of creating and deleting specific types of audio devices internally. So when the device is changed, your callbacks will just keep running without having to worry about this.
[/quote]
The question is : what happens if we have several of those ? The class has a constructor so we are able to create as many as we want. However, is this going to lead to an undefined behaviour ? (I guess the answer is yes, but just wanna check)
Not really. It needs to open a device before it can ask it about properties like supported sample rates, etc.
Yeah, it’s all very platform-specific. I’ve thought about doing this, but it’s quite fiddly and I’ve just never found the time to write and test it.
Depends which type of devices you use - things like CoreAudio would probably be fine, but ASIO has problems if you try to open more than one device simultaneously.
I observed other applications doing this with an ASIO device, so this capability must be in ASIO somewhere. But I looked at the Steinberg SDK headers and I don’t see where the communication could take place. Can you please point me in a direction that I can explore? Because I’m interested in doing this. I can report my findings, and I can provide code if I get it working. Obviously DirectSound is gonna be platform specific (hehe).
Once you’ve opened an ASIO device it can tell you when its own properties change - there are already hooks for that in my code. But I don’t think it’d be possible to find out about changes to devices that aren’t open.
Ah I see! sampleRateChangedCallback() is empty though.
The way the Fireface 400 works is there is a separate configuration dialog that you bring up from a background service (it sits in the taskbar if you let it). From there you choose the buffer size and some sample rate parameters. When going through ASIO, the FireFace doesn’t give you more than one choice of buffer size, you have to use the external configuration dialog to set it.
After you change it with the external dialog, I was imagining that juce would receive a callback and somehow my Component would get notified, perhaps through a Listener or ChangeBroadcaster on the asio AudioIODevice?
