[BUG] Connecting / disconnecting headphones kills audio

with the latest tip (4.2.4), if I connect headphones on my mac while audio is running, I can’t hear anything. Unplugging and replugging don’t solve the issue.
Before this commit everything seemed to work like a charm:

To replicate the issue, just create an audio app, add a ToneGeneratorAudioSource and plug your headphones after the app has started.

1 Like

Anyone else experiencing this?

Steps to reproduce the problem:

  • Create an audio app with Projucer using latest 4.2.4 master version of Juce
  • Replace the MainContentComponent class with the one below
  • Launch the app without any headphones connected to the mac
  • Listen to the tone playing
  • Plug headphones in
  • Hear nothing
  • Disconnect headphones
  • Hear nothing

Expected result:

  • Tone should keep playing when connecting headphones
  • Tone should keep playing after disconnecting headphones


MacBookPro running El Capitan 10.11.2
Apple EarPods
Xcode 7
Juce 4.2.4

Does this help?

class MainContentComponent   : public AudioAppComponent

setSize (800, 600);


    setAudioChannels (2, 2);


void prepareToPlay (int samplesPerBlockExpected, double sampleRate) override
    source.prepareToPlay(samplesPerBlockExpected, sampleRate);

void getNextAudioBlock (const AudioSourceChannelInfo& bufferToFill) override

void releaseResources() override

void paint (Graphics& g) override
    g.fillAll (Colours::black);

void resized() override


ToneGeneratorAudioSource source;



1 Like

Hi @masshacker, I can reproduce this. We are really busy with ADC here so I’ve put this bug into our internal bug tracker. It will have to wait until after ADC, I’m afraid.


Hi @masshacker,

Thank you very much for the clear instructions! However, even with your guidance, I can’t reproduce this problem.

After I plug my headphones in I still hear the tone in the headphones (after a short delay, maybe about 0.3 of a second), then I hear the tone again from my laptop when I unplug (again, after a short delay).

If you open the OS X Sound Preferences, what do you see on the Output tab when you insert and remove your headphones? I see “Internal Speakers - Built-in” change to “Headphones - Headphone port”. The commit you listed above stops the audio when there are internal changes to aggregate audio devices. Are you using one of those?


Hi Tom,
thanks for looking into this.
Unfortunately I don’t have access to the laptop I’ve used for the test right now, but I’m going to check tonight. Also, I’m unable to reproduce the issue with the iMac I’m using at work.
@fabian On what setup were you able to reproduce this? Were you using aggregate devices perhaps?

Sorry this was on iOS - which seems to be separate bug.

Alright, this is officially driving me nuts. Thank you, CoreAudio.
First of all: I’m not using any aggregate devices on my laptop, and I don’t even have one listed in the devices list.
When I plug the headset in, I see the same thing you are seeing in OS X Sound Preferences, @t0m.
I’ve debugged a little what is happening in juce_mac_CoreAudio.cpp, and on my laptop the deviceListenerProc is clearly passing a kAudioObjectPropertyOwnedObjects selector, although I’m not using an aggregate device.
This is not happening on 3 other machines I’ve performed tests on.
I tried to reboot the machine, something that I haven’t done in months (“have you tried turning it off and on again?”) but nothing changed.
The next thing I’m going to try is to update the OS, maybe something has changed between 10.11.2 and 10.11.6.
Also, maybe this is worth noting, my machine is from 2009.
I’ll keep you updated with my progress.

Perhaps we need to attempt to maintain the audio stream if the corresponding number of IO channels and sample rates are unchanged, but I’d like to understand the difference between your laptop and mine first.

I completely agree.
Meanwhile, updating to 10.11.6 solved nothing.

Quick follow up: as soon as I get some spare time I’m going to log the sequence of property changes that are triggered in the deviceListenerProc on my setup, and I’m going to paste it it here.
If I remember correctly I saw a bunch of properties that were not considered at all within the callback, maybe those could help you in narrowing this thing down.

Brilliant, thank you.