CoreAudio cpu load


With the standard Juce audio setup, done with an AudioDeviceManager initialized with 0 input channel, juce seems to always start an IOCallback for the input device. That unused input is then taking 2.5% of cpu on my macbook (using the internal soundcard), which is small, but noticeable. If I strip the “audioInputDeviceName” from the saved xml state, then the input device iocallback is not started but it would probably be better not to open it in the first place for applications that do not intend to input audio. Or did I miss something obvious ?


Well, yes, it should certainly be optimised to avoid opening the input device - but I’m surprised it could take 2.5% cpu just to run an input device! Are you sure that’s how much it takes?

Maybe a few tweaks to juce_AudioDeviceManager.cpp line 370 might sort you out:

[code] const String newInputDeviceName (newSetup.inputChannels.isEmpty() ? String::empty : newSetup.inputDeviceName);
const String newOutputDeviceName (newSetup.outputChannels.isEmpty() ? String::empty : newSetup.outputDeviceName);

if (currentSetup.inputDeviceName != newInputDeviceName
     || currentSetup.outputDeviceName != newOutputDeviceName
     || currentAudioDevice == 0)

    if (newOutputDeviceName.isNotEmpty()
         && ! type->getDeviceNames (false).contains (newOutputDeviceName))
        return "No such device: " + newOutputDeviceName;

    if (newInputDeviceName.isNotEmpty()
         && ! type->getDeviceNames (true).contains (newInputDeviceName))
        return "No such device: " + newInputDeviceName;

    currentAudioDevice = type->createDevice (newOutputDeviceName, newInputDeviceName);



It does, according to both “top” and the activity monitor. When the input device is running , they both say 10% - 10.5% of cpu for my application (while it is idle), and when the input is not running, they say its cpu consumption is 7 to 8%. Note that I cannot reproduce that on a powerbook running 10.4 , which does not seem to be sensitive to the input callback. I don’t know if it is due to the hardware difference between the two, or the macos version (the macbook is running 10.5)

Your patch seems to disable all audio , I cannot select any output device (I have to use newOutputDeviceName=newSetup.outputDeviceName to get some output)


Sorry - I didn’t actually test that, of course. This seems to work though:

const String newInputDeviceName ((newSetup.inputChannels.isEmpty() && ! newSetup.useDefaultInputChannels) ? String::empty : newSetup.inputDeviceName);
const String newOutputDeviceName ((newSetup.outputChannels.isEmpty() && ! newSetup.useDefaultOutputChannels) ? String::empty : newSetup.outputDeviceName);
const String oldInputDeviceName ((currentSetup.inputChannels.isEmpty() && ! currentSetup.useDefaultInputChannels) ? String::empty : currentSetup.inputDeviceName);
const String oldOutputDeviceName ((currentSetup.outputChannels.isEmpty() && ! currentSetup.useDefaultOutputChannels) ? String::empty : currentSetup.outputDeviceName);

if (oldInputDeviceName != newInputDeviceName
     || oldOutputDeviceName != newOutputDeviceName
     || currentAudioDevice == 0)


yep it works but it is still instanciating the input device :wink:

If I use

then it seems to work, and it does not instanciate the input device !


Actually, thinking about it, this might be all that’s needed:

[code] const String newInputDeviceName (numInputChansNeeded == 0 ? String::empty : newSetup.inputDeviceName);
const String newOutputDeviceName (numOutputChansNeeded == 0 ? String::empty : newSetup.outputDeviceName);

if (currentSetup.inputDeviceName != newInputDeviceName
     || currentSetup.inputDeviceName != newOutputDeviceName
     || currentAudioDevice == 0)



Yes it’s working fine that way !