I’ve been building my app on the latest version of Mac OS/X, with JUCE v5.3.2 and it runs fine when I record through my iMac’s built in microphone. But if I’m recording a second track, it becomes neccessary to use headphones, and so I connect my bluetooth BOSE headphones.
This causes the audio callback to crash immediately on an assertion because it is expecting there to be two output channels but finds only one object in the outputChannelInfo array. You can see this in the screenshot below.
My best guess for why this issue only occurs with this device, is that it is something to do with the fact that these headphone’s input channel forces a sampling rate of 16000 while the recording is enabled. But the output device for the headphones desires a sampling rate of 48000. So, perhaps there was some unforeseen logic error in JUCE’s code that is not handling this situation very well.
Perhaps I’m not making any sense and my observation is not useful, but I can’t think of any other reason why the headset works fine in JUCE so long as I don’t require any input channels. And the headset is working just fine when I use Apple’s Voice Memo app to make a recording. So, there is no hardware issue here, and seemingly no operating system issue. So, it would seem that there is indeed a bug in how JUCE sets up the audio device.
As a workaround, I can always plug my headphones in via a cable, but this doesn’t deal with the main issue: if anybody else chooses to run my app it could crash as soon as they connect their bluetooth headset.
By the way, just to clarify, this bug started before I recently upgraded to Mojave. And so all of what I said in the previous comment applies to the previous version of OS/X. But something important that I would like to add, is that now that I have upgraded to Mojave I actually don’t seem to be able to record anything at all regardless of audio device.
I tried using the JUCE audio recording demo which had been compiled on the previous operating system and it worked just fine. Then I compiled it again on Mojave and it is no longer able to record audio. It just picks up silence.
Are you able to give me some indication of the status of the headphone bug? This is a serious issue for me and I have to make a business decision about whether to stick with JUCE Pro long term or if I am better off transitioning to either another framework or my own code base. That is, it’s hard to justify working with JUCE if I can’t trust that my app will be able to run under such ordinary circumstances.
Just curious, do you think the majority of your customers will be using the built-in interface on OSX or do you anticipate them having some 3rd party audio interface? i.e., are you experiencing the bluetooth bug because you don’t have a separate audio interface? Maybe most of your customers will be studio guys with gear…?
My app is targetted at a mass market audience. It is targetted at musicians who might only know how to sing, rap or play an instrument, but who want to do more. For now, we’re focusing on using AI to collaborate with our users on compositions. We don’t even have audio effects yet, so I don’t think studio guys will be as excited in our product in the beginning.
I’ve been looking into this and I’m struggling to reproduce the crash that you’re experiencing.
I’ve been testing this with a pair of bluetooth headphones which similarly have a sample rate of 16kHz and I get an error message when selecting them as the input device (both via the AudioDeviceSelectorComponent and by manually calling AudioDeviceManager::initialise() when I detect that the headphones have been connected) which says “Couldn’t change sample rate” - this is expected as the built-in output only supports sample rates of 44.1kHz and above but the audio device is torn down correctly after this message so there is no crash.
How exactly are you selecting the bluetooth headphones mic as the input device when it’s connected? It’d help to track this down if you could provide a minimal test app which reproduces the crash.
This has definitely stopped the crash from happening and it seems to be working fine. I’m just up to my armpits in code drama right now, so it’s hard for me to verify thoroughly. I’ll get back to you if I find that there are still problems.
