Asserts in JUCE Demo with some audio device combinations

The following assertion is easy to produce if one has a mac and a pair of AirPods around (or any other device with non-standard input sample rate):

  • Have AirPods connected and set as the system’s default audio device
  • Run JUCE’s DemoRunner
  • Choose the “AudioAppDemo”
  • Go to the settings. It should show that the AirPods are used for both output and input
  • Switch the output to “Built-in Output”. This triggers an assertion AudioSourcePlayer::audioDeviceIOCallback because its sample-rate value is zero

This happens because AudioIODeviceCombiner::getAvailableSampleRates() finds the common rates between the AirPods’ mic {16000} and the rates of the built in output {44100, 48000, 96000} (at least with 10.14.6 on a 2016 MacBook Pro), which is {}, so it returns 0.

Perhaps AudioDeviceSelectorComponent should automatically disable the input device if choosing an output device that is incompatible with it and vice versa?

1 Like

can the input device resample to the requested samplerate of the output? i find a bit limiting not being able to use a device because by bad luck has a different samplerate than the output device

that would be nice too, but JUCE doesn’t yet have a good sample rate conversion so I wouldn’t expect it

so at least not to crash would be nice

ahah yeah that sucks, i was considering already done a bump to a more up to date algo after i first saw it in the library more than 13 years ago