For some reason, we’re seeing audio break-up on macOS when connected to some wireless headphones in certain configurations.
For example, with my AirPods Pro Max, I can run perfectly at 24000 Hz, but the audio breaks-up at 48000 Hertz. No such issues with any other audio device types.
Just wondering if anybody has any suggestions!
Best regards, Pete
What architecture/environment? M1/MacOS, M1/iOS, Intel/iOS?
Thanks for asking! M1 Mac, running macOS 13.01
Hi, I also had a similar experience.
In the case of using a Bluetooth headphone device, there is no problem when using only the output device. (I can hear it well at 48k)
However, when using a Bluetooth input device together, the sample rate of the output device changes(48k to 24k), so sounds strange.
JUCE’s AudioProcessor’s sample rate is still set to 48k, but the Bluetooth device’s sample rate has changed to 24k.
In my opinion, there might be a problem with the callback function(
juce_mac_CoreAudio.cpp) logic according to the device change.
static OSStatus deviceListenerProc (AudioDeviceID /*inDevice*/, UInt32 /*inLine*/,
const AudioObjectPropertyAddress* pa, void* inClientData)
auto intern = static_cast<CoreAudioInternal*> (inClientData);
intern->deviceDetailsChanged(); // <- I fix this.
I checked it as a work-around, and it seemed to work if I modified it like the code above.
My device device info is below.
- MacOS 11.6 Intel
- JUCE v7.0.4
Best regards, Jack!
Nice find - could you please push this forward for testing…
I don’t think his forward is the exact solution.
I’m looking into it more, and I’ll let you know if I find out anything more.
I made PR for your testing, here!
@reuk Please, review this issue and leave comments
I have exactly the same issue with iOS 16.3.1 and macOS 13.2.1, both with AirPods Max and AirPods Pro. Leaving audio input open results in an error and abrupt application termination. Setting setAudioChannels (0, 2) solves the issue, however this way I will unable to transmit audio into application via bluetooth mic.
I checked too. In addition to the sample rate issue mentioned above, there was also a problem with the channel settings.
When using a BLE microphone (such as phone call mode?), the speaker’s stream information is fixed to mono, 16k (or 24k). Originally it was stereo, 48k.
Are there any plans to fix this in the relatively near future?
There seem to be at least a handful of developers who have seen the same issue; and presumably, many end-users of our software (!)
Best wishes to all, Pete
This has been an issue for ages. Would be great to finally fix! So many consumers use AirPods which tend to crash JUCE applications as well
As a JUCE developer working in a hardware manufacturer (Austrian Audio) where we will, inevitably, run into this issue on our service front-lines, I’m willing to help test this fix with many bluetooth use cases if that is all that is needed to get it into mainline…
I no longer listen to music because of this issue. It’s impossible to work on a juce product and wear headphones at the same time.
I now sit in silence all day… plz help…
I think this might have been improved in version 7.0.6. See [bug] CoreAudioInternal can miss device property changes.
Hi @jdv many thanks for the pointer - alas, this patch didn’t solve it for me.
Has anybody else had any success with the latest JUCE version?
Best wishes to all,
For the record, just tried with JUCE 7.0.7 - the audio still breaks up.
Best wishes, Pete