# Asserts in JUCE Demo with some audio device combinations

**URL:** <https://forum.juce.com/t/asserts-in-juce-demo-with-some-audio-device-combinations/40249>\
**Category:** MacOSX and iOS\
**Created:** [June 21, 2020, 5:23pm UTC](https://forum.juce.com/t/asserts-in-juce-demo-with-some-audio-device-combinations/40249 "2020-06-21T17:23:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![yairadix](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yairadix/32/1114_2.png) [@yairadix](https://forum.juce.com/u/yairadix)\
**Post date:** [June 21, 2020, 5:23pm UTC](https://forum.juce.com/t/asserts-in-juce-demo-with-some-audio-device-combinations/40249/1 "2020-06-21T17:23:06Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [June 21, 2020, 5:41pm UTC](https://forum.juce.com/t/asserts-in-juce-demo-with-some-audio-device-combinations/40249/2 "2020-06-21T17:41:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![yairadix](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yairadix/32/1114_2.png) [@yairadix](https://forum.juce.com/u/yairadix)\
**Post date:** [June 21, 2020, 7:59pm UTC](https://forum.juce.com/t/asserts-in-juce-demo-with-some-audio-device-combinations/40249/3 "2020-06-21T19:59:32Z")

</div>

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

 ![img](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/5/59bd8732fbeaf9cddd8f2170272304d66243fb3c.jpeg)

so at least not to crash would be nice

---

<div class="post-metadata">

**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\
**Post date:** [June 21, 2020, 8:14pm UTC](https://forum.juce.com/t/asserts-in-juce-demo-with-some-audio-device-combinations/40249/4 "2020-06-21T20:14:16Z")

</div>

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