[Openal] Defective ALC_ENUMERATION_EXT support on Mac OS X / Need OpenAL community's support

[Chris Robinson]

On Wednesday 07 January 2009 14:23:31 Bob Aron wrote:
> I don't know that the user could ever rely on the device names in the
> list to have any specific meaning. Truly on OSX, the  "default" device
> has a meaning on the system which is the user selected device (via the
> System Pref panel). The behavior of the system is that a new device
> will be chosen as the "default" device if the user's device goes
> away.

Yes, this is what I mean by a meta-device. Just instead of the implementation 
handling it, it's the underlying system (same as if ALSA or PulseAudio 
implicitly changed the output device on OpenAL Soft's ALSA backend). An OSX 
user would see "Default Output", or whatever it's called, and could infer this 
means the default system behavior that auto-switches as needed (and even if 
they don't, it would be the device selected by NULL, getting the default 
system behavior anyway).

> I think the 'auto switching' and 'device selection' aspects of this
> discussion are really two separate entities. The implementation is
> going to decide (if possible) if it can auto switch and this may or
> may not be decided by the type of devices available on the system. For
> OSX this is a no brainer as we are working entirely in sw and
> rendering to all devices is the same. I assume it is a bit more
> complicated when you have different kinds of sound  hw. It really
> isn't the 'device' that dictates the auto switching capabilities but
> the implementation's ability to manage the set of devices available.

Well, it is partly the device. As I mentioned before, if the user selects a 
device that has EAX5, you can't really change to another device that doesn't 
also have EAX5 or the app will inexplicably lose capabilities and extensions 
at run-time (though the inverse is possible: you can switch from a non-EAX5 
device to an EAX5 device, and then back; it depends on what device was 
initially selected).

My main point, though, is that an implementation/system may be able to auto-
switch between certain devices, but NULL may not always select a device that 
can be switched out. Having ALC_EXT_disconnect say that the NULL device may 
switch between individual devices on some systems without issuing a disconnect 
error, while explicit devices don't, then becomes misleading if not plain 
untrue. OpenAL would just need to report disconnection if it itself loses a 
usable device handle from the system, not simply if the system lost the 
device.

> Maybe it would be better for the implementation to have a mechanism to
> indicate whether it can auto-switch and leave the device selection as
> it is, i.e. NULL (default) and a list of actual devices. It could even
> indicate, based on the device selected device if auto switch is
> available. This seems cleaner to me than defining some meta-device
> that would then have to adhere to some set of behaviors which may or
> may not be possible per platform implementation.

Having OpenAL indicate that it can auto-switch from lost devices seems a bit 
out of scope. Unless it's simple (eg. reopening the "default" device), it 
seems to be rather non-trivial, and it would be better to just fail and report 
disconnection. I basically meant "meta-device" as more of a concept than a 
defined OpenAL term that gives defined behaviors.