When it’s started AudioSwitcher uses the AudioObject and AudioDevice APIs to interrogate all of the available audio devices, it tries to determine some of their capabilities (volume, sample rate etc) and then creates logical structures to ‘watch’ those devices for changes. It also handles directly altering some of those devices capabilities, most notably volume, sample rate and whether the device is currently the default input or output device.
Yes. If you’ve got a device that OS X thinks is a capable of sound output it should work regardless of the connection type, USB, Bluetooth, AirPlay etc.
N.B. If your device relies on a vendor supplied driver you need to ensure that driver supports interaction with sandboxed applications (like AudioSwitcher). Check with the vendor for an update.
I’ve noticed with some inexpensive USB devices that if you attempt to set the volume on the device when it (or one of its other datasources) is not the default device the volume selection can fail. AudioSwitcher in that case will keep the slider where it was previously. Normally trying again will be successful. My experience has been that if one of the other datasources on the device is the current default the problem doesn’t occur. For example, I’ve got a cheap Xenta 7.1 USB sound card with four inputs (Mic, Line, SPDIF and another line level input). If none of those inputs is the current default input then volume change can occasionally fail. If any of those inputs is the default then altering volume on the other inputs is always successful and fast.
Because it seems that Apple no longer want you to be able to although it depends on which version of OS X you’re using. It was available under 10.8 but has changed / been removed in 10.9, 10.10 and onwards. We raised a ticket with Apple when this functionality was removed in 10.9 and received the following response..
‘.. there are no plans to resolve this’
which is an somewhat impolite way of saying this feature is no longer available. You’re unable to output to multiple air play devices on a selective basis.
I would strongly urge you to register this as a bug at https://bugreport.apple.com
Update 14/8/2015: With 10.10 onwards (Yosemite and El Capitan) it seems you only output to one AirPlay device at a time
The method used to create multiple devices is really geared towards what is sometimes (but not always accurately) called ‘pro’ level equipment with its own clock source and a physical (USB, FW, Thunderbolt) connection to the Mac.
Because HDMI doesn’t have a volume that can be altered, HDMI carries an encoded, digital audio signal which is normalised; it’s not supposed to be altered at the source but by the output device.
To change the volume on your Mac would mean unpacking that audio signal, fiddling with possibly multiple channels and repackaging it before sending it to the source. There’s a general rule of thumb that you should limit the number of times you alter any signal; Apple would seem to take the view, correctly in my opinion, that any decoding or alteration of the audio signal should take place at the output device. Inconvenient? Maybe. Technically correct? Yes.
I don’t know – perhaps they unpack the signal and repackage it? Perhaps you have hardware support for HDMI-CEC with a dongle.
i) Bandwidth costs me real money. The total donations to the site in the whole of 2013 covered 2 weeks of hosting costs. Now I’m clearly not in this for the money but having Apple servers do the heavy lifting is a big saving both financially and technically. ii) For better or for worse the App Store is a great shop window: The number of people who download my apps from the App Store exceed all of the other sources combined by a factor of twenty. iii) Support: There are technical differences between even apps which are identical in functionality when they’re packaged for the App Store. Around half the support requests I deal with have arisen as a direct result of these differences. Having just one download source has significantly reduce these problems.
The sound is probably an artefact caused by the devices losing synchronisation with each other. It seems that the problem has become more pronounced with more recent versions of OS X. I’ve raised it as a bug with Apple and received the following response:
“Engineering has determined that there are no plans to address this issue”
I would encourage users to register a bug report with Apple here: https://bugreport.apple.com/
To be fair to Apple the method used to create multiple devices is really geared towards what is sometimes (but not always accurately) called ‘pro’ level equipment with its own clock source. If you don’t have an external word clock or know (or care) what one is then your gear probably isn’t going be able to synchronise itself all that accurately. Attempting to synchronise, for example, a wireless device and a consumer USB device is unlikely to work well though YMMV.
I’ve got a cheap USB device that is configured on the input side to have multiple data sources for SPDIF, Line in, Mic etc. Every now and then it starts triggering changes across all it’s datasources repeatedly – this causes AudioSwitcher (and Core Audio) to start trying to handle those changes which in AudioSwitcher’s case can cause the interface to lock up. Some users have reported a similar problem with older AirPlay devices – AirPlay devices appear to the system as one device, again, with multiple data sources.
This setting causes AudioSwitcher to try and smooth out those rapid changes to prevent lock ups and allow the device to settle. You might find it useful in this kind of situation
There’s a bug with 2.24.932 which will prevent startup in some situtations. The quickest fix is to reset the user defaults for AudioSwitcher.
1. Quit AudioSwitcher if running
2. Open a terminal window and issue the command:
defaults delete uk.co.serialangels.audioswitcher
The user defaults system can cache defaults so you may need to restart AudioSwitcher a couple of times for it to pick up the changes. Fix is en route