macOS - wireless headphones at some sample rates?

MacOSX and iOS
1

Hi Folks,

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

2

What architecture/environment? M1/MacOS, M1/iOS, Intel/iOS?

1 Like
3

Hi @austrianaudioJV,

Thanks for asking! M1 Mac, running macOS 13.01

Pete

4

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(deviceListenerProc() at 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);

        switch (pa->mSelector)
        {
            case kAudioDeviceProcessorOverload:
                intern->xruns++;
                break;

            case kAudioDevicePropertyBufferSize:
            case kAudioDevicePropertyBufferFrameSize:
            case kAudioDevicePropertyNominalSampleRate:
            case kAudioDevicePropertyStreamFormat:
            case kAudioDevicePropertyDeviceIsAlive:
            case kAudioStreamPropertyPhysicalFormat:
                intern->deviceDetailsChanged();
                break;

            case kAudioDevicePropertyDeviceHasChanged:
            case kAudioObjectPropertyOwnedObjects:
                intern->deviceDetailsChanged(); // <- I fix this.
                intern->deviceRequestedRestart();
                break;

            case kAudioDevicePropertyBufferSizeRange:
            case kAudioDevicePropertyVolumeScalar:
            case kAudioDevicePropertyMute:
            case kAudioDevicePropertyPlayThru:
            case kAudioDevicePropertyDataSource:
            case kAudioDevicePropertyDeviceIsRunning:
                break;
        }

        return noErr;
    }

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!

4 Likes
5

Nice find - could you please push this forward for testing…

6

Great work @JackNoh !

Pete

7

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!

8

@reuk Please, review this issue and leave comments

9

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.

10

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.

11

Hi @reuk!

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