[vlc-devel] Interesting issue with Mac audio devices

[Felix Paul Kühne]

Hi Ron,

On 03.09.2012, at 18:53, Ron Frederick wrote:

> Now that I'm using HDMI audio out from my Mac to my TV, I've noticed an interesting problem with VLC. Whenever I power the TV on & off, the Mac loses track of the audio device corresponding to the HDMI audio out.
This is fixed in the current development source for VLC 2.0.4 and 2.1.

> Later, when the TV is turned back on, a new audio device is added, but it has a different device ID than it did before. 
This sounds like a bug to me. Not in VLC though, but in CoreAudio. Which OS X version do you use?

> With the way VLC is currently designed, this generally causes it to fall back to the default audio output, and I need to manually select the HDMI audio out again after I begin playing a file (since you can't change the audio output when nothing is being played).
This is correct, however it shouldn't happen anymore (see above).

> This issue with device IDs not being stable also affects the VLC preferences for default audio device. [...cut...] VLC does this by adding 0xF00000 to the device ID, and you so end up with a preference value of something like 15728712 (0xF00048) if the device ID you want is 0x48.
This is not VLC, but CoreAudio, all we are storing is the AudioDeviceID provided by the AudioUnit API (see modules/audio_output/auhal.c:313).

> It would be great if VLC could store the preferred audio device as something like a string value, matching what appears in the "Audio Device" menu.
This sounds like a hack to me, since what we display is a so-called "user-readible string" provided by the AudioUnit API. I doubt that there is a clean way to see which user-string patches which AudioDeviceID. An AudioDeviceID is required to set the kAudioOutputUnitProperty_CurrentDevice property correctly to choose the physical audio output device to use.

> That way, each time it begins a new playback, it could iterate through all of the currently available audio devices and try to match the value the user had selected before, even if the device ID had changed.
See above, this doesn't sound particularly clean to me.

For multiple screens, we basically have the same situation: you can select your default fullscreen device, which could be an external screen. Let's assume it is one. If you unplug and start a clip, VLC will be play on the internal screen (fallback). If you take your Mac to a friend's place, attach a different external screen, VLC will play on the internal screen (fallback), since the external screens don't have the same ID. However, if you're finally heading home and attach your default device, it will play on the external screen again.
CoreAudio, in fact, is supposed to work exactly the same way.

> Also, since there are separate menu items in this menu for the "encoded output" of devices capable of that, it would avoid the issue above about needing to know the VLC internal device numbering for that.
Well, this setting is not supposed to be user-settable, precisely for the fact that no-one is usually able to predict the AudioDeviceID.

> Does this seem like a reasonable change? If so, I may see if I can check out the latest sources and take a crack at it.
Well, please report your OS X version first, so I can try to reproduce your problem. I worked on this code last weekend using some external USB audio device and it was behaving correctly. Your described problem was not exposed in my fixed code. So, you might want to compile the current code first :)

Thanks for your detailed feedback!

Felix


--
VideoLAN
Felix Paul Kühne
Developer of VLC's Mac OS X port
www.videolan.org