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

[Bob Aron]

On Jan 7, 2009, at 11:07 AM, Chris Robinson wrote:

>> It could certainly do that, but then applications would be in the
>> business of parsing implementation-specific strings to find it, or
>> forcing the user to select it from a list. NULL is the cleaner way to
>> request this behaviour, for platforms that support it.
>
> Or the meta-device could be the default device, so opening NULL would
> implicitly select it when available. To me, it seems like something  
> the user
> would tell from looking at the device name list, or the  
> implementation would
> handle smartly, than to try to pragmatically tell which devices are  
> meta-
> devices.

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.  If it returns, the system knows and will restore the device  
back to the default. The current Mac implementation of OpenAL  doesn't  
even know if this device goes away. It may receive a format change  
notification to accommodate a sample rate or channel count change, but  
the implementation doesn't know (or need to know) if this is due to a  
change TO the device itself, or a change to a DIFFERENT device. All  
apps (iTunes, QuickTime, etc etc) that render to the default device  
will continue rendering (when possible) if the default device comes  
and goes.

>
>
>>> IMO, letting work through meta-devices would be better overall  
>>> than only
>>> specifying that NULL can do it. It allows implementations to be  
>>> smarter
>>> about device groups, even possibly giving more options for the  
>>> user (eg.
>>> don't switch to speakers if these headphones are lost).
>>
>> I don't think the extension prevents this sort of behaviour. For  
>> power
>> users, such a meta-device could be very useful, but it's out of scope
>> for ALC_EXT_disconnect.
>
> I think it's a bit misleading, in the end. It gives the impression  
> that if you
> want a device that can reconnect to other physical devices, you need  
> to use
> NULL, since no other devices can switch. It seems to be an  
> implementation
> detail for a given device name than something that may be possible  
> behavior
> for a special NULL device.
>
> As an example, Creative's drivers have a "Generic Software" device,  
> where
> there's no reason it can't auto-switch; but users would be  
> encouraged to
> select NULL for that behavior instead, where it would pick "Generic  
> Hardware"
> if available, preventing auto-switching.
>
> And if you can't guarantee that NULL will select a device capable of  
> auto-
> switching, when there are some that may be able to, it becomes  
> impossible to
> rely on and has no point, IMO.


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.

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.

-bob aron

___________________________________________
CoreAudio Team • Apple Inc.
baron at apple.com • (408) 974-1221

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://opensource.creative.com/pipermail/openal/attachments/20090107/0b3d898e/attachment.html