AudioDeviceSelectorComponent doesn't show correct buf. size


Repro: Post dialog containing AudioDeviceSelectorComponent, select “show this device’s control panel” and change the buffer size in the device native control panel. The AudioDeviceSelectorComponent dropdown for buffer size does not show the change. The change is made though; if the app is restarted or if the control panel is accessed from somewhere else, the correct size is shown. The buffer size changes correctly if done through AudioDeviceSelectorComponent’s combo box.

On my machine, the audio dies (audioDeviceIOCallback is not called) if I change any parameters through the native control panel launched by AudioDeviceSelectorComponent. I’ve tried this with 3 devices (Tascam US-122, Line 6 Tone Port GX, Novation X-Station). On the Line 6, matching the buffer size in the component combo box restores the audio. For the Tascam, the combo box only shows the old size unless I chose another driver and then go back to the Tascam. In this case the correct buffer size is already selected and audio is restored. On the Novation, changing any parameters from the AudioDeviceSelectorComponent launched native control panel crashes the app inside the novation driver; this is one of several instabilities I’ve noticed when using the Novation driver with Juce.

This appears to be a bug in synchronizing information between the device manager and the selector component as the only thing my code does is launch the component. Is it even possible for the application to get a callback if the user changes something in the native device control panel? At some level it must be because the native device control panel has to conform to the OS’s management APIs.


I seem to remember fixing that one… Are you using the tip from SVN?


I’m using the October 07 release (1.45). I’ll check in SVN for the fix. Thanks!


I think I found the fix; it’s in version 360 of AudioIODeviceCallback and several other objects (a pointer the device is passed in to audioDeviceAboutToStart instead of sample rate and buffer size). I’m not sure how this fixes the problem except that it gives the application a chance to touch the driver right after the change is made. I looked in device specific code and couldn’t find anything.

Regardless, using the code from Subversion is problematic, since there’s other changes and dependencies among the source code. I wasn’t able to get the framework to compile–each time I found a problem, I had to download more source from Subversion. Is there a way to download the source from Subversion other than by single files? At this point it seems more productive just to wait until you’ve got a new release as I’ve got a work around for the bug.


You can check out the whole directory in one go. Probably not a bad idea, as it’s pretty stable at the moment.


I checked out the directory and rebuilt my app. The driver code appears more stable, for example I can get the Novation control panel to come up without crashing. I still can’t change anything from the control panel without the driver throwing an exception and bringing down everything. Since it’s the driver, I have no debug info at the app level to determine what went wrong.

The original problem I wrote about is not fixed through: you can’t change anything from the control panel launched by the AudioDeviceSelectorComponent and either see the change or hear it (audio is killed); you have to swap out the driver with another and then put back the original driver to see or hear the change. Also, I’m not getting audioDeviceAboutToStart called when changing stuff from the control launched by the AudioDeviceSelectorComponent.


The UI is supposed to refresh itself when you close the device’s control panel, and I’ve never seen any problems on other soundcards (though I’ve not got any of the ones you mention). Probably the best solution would be for the device manager to shut down any audio while the control panel is open, in case this driver is getting confused by trying to change parameters while it’s running.