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

[E. Wing]

It looks like I unwittingly let the genie out of the bottle. Sorry
about that. (But I'm still right that being to access non-default
devices can be appropriate :) )

So I'm probably way out of my league here, but I had a few thoughts.


> I'm also not sure I like the fact of the default (NULL) device behaving
> differently once selected. Personally I'm not sure it should even behave
> differently from selecting *the* default device given the language of the
> spec, but I can see the use in automatically selecting any useable device.


I think I'm in agreement that special-casing just the default device
(NULL) for auto-switching is a bit strange and inelegant. But I will
go out on a limb and approach it from the other direction. I think the
auto-switching should be applied to everything, not just the default
device.


>From a pure user-experience stand-point and ignoring the technical, I
think auto-switching is the most expected and desirable behavior.

This following very simple example came to me because I noticed that
System Preferences/Core Audio was changing the name of my default
device automatically between Headphones and Internal Speakers. It got
me thinking that these could indeed be considered two
distinct/separate devices and if you use this idea for a simple
thought exercise, it helps underline what user-expectation really is.


So take for example, headphones and think of it as your unpluggable
USB device. If a user (accidentally or not) unplugs them, they
immediately hear the sound switch to their speakers. Two important
things happen here: 1) The user has immediate feedback that something
changed (their headphones were unplugged and hear sound come from
speakers), 2) The application continued working (and without
interfering with normal operation and avoiding nagging alert dialogs)

If the user deems necessary, they will replug the headphones. This
illustrates important behavior 3) The user can easily undo the action
by simply replugging (No restart required). But maybe the user is
content with the new arrangement (or unplugged intentionally) so
things just keep going.


I don't think most users would like to see their program halt with an
alert (or crash) anytime the headphones are removed in the middle. Nor
do I think the user would appreciate resetting a configuration or
restarting their program when they plug the headphones back in.


So I see this breaking down into 3 basic cases plus some corner cases:

Case 1: User picks default device and device is changed via system preferences
    Result: The device should switch to the new default. (Like iTunes)
    Followup: Selected non-default devices should not be affected by a
change in the default device from system preferences.

Case 2: User picks non-default device and device is unplugged
    Result: The device should switch to the system default.
    Followup: If the device is replugged, should it switch back? Seems
the answer is yes if you follow the headphone example.

Case 3: User picks default-device and device is unplugged
    Result: I presume the OS automatically selects a new default
device, so the device should automatically switch to the newly elected
default device.
    Followup: If the device is replugged, should it switch back? Does
the OS automatically reset the replugged device as the default device?
In either case, I think the result should follow what the system
default device is/becomes.

(Corner) Case 4: User picks a device that also happens to be the default device.
     Result: This is not considered a default device, and will follow Case 2.

(Corner) Case 5: Start with Case 2, which results in a fallback to a
default device. Then go to case 3 where the default device is
unplugged, which results in another default device being elected. Then
the user replugs the first device back in.
     Result: Switch back to replugged device?
     Followup: Add a few more layers of indirection here and
intermediate devices being unplugged/replugged.


Final thought on this. I don't expect OpenAL API users are going to
code this themselves and if they do, we will see a hodge-podge of
different behaviors which I don't think is good for user experience. I
think the more that this can be transparently handled by the
underlying OpenAL implementations, the better. But I know I just
completely ignored all the technical challenges, so back to the
regular program.



>>    I'd think an implementation could do that by exposing a meta-device, of sorts. Like how OpenAL
>> Soft gives a "ALSA Software on default" device, if the current default device is disconnected, it
>> could reopen the new default device, and continue on with that, leaving the app none-the-wiser.
>> Open a specific one, like "ALSA Software on HDA NVidia [ALC883 Analog]", and it wouldn't.


> 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.

I think it would almost have to be requiring the user to select it
from a list and the developer won't be able to easily drop in hard
coded strings because they won't know those strings a-priori. In
addition, if the names are localized, it will be very hard for a
developer to hard code something because they must figure out all
localizations of the names which could eventually change due to users
renaming devices or operating system updates renaming devices.



>> I amended the spec to say the string survives until the next query,
>> which implies "you should use a mutex, if you really need to get the
>> device list in two threads at once for some reason".
>>
>> I also warn that device enumeration may no longer be a "fast call,"
>> since device (re)detection may now be happening on each query.
>
> Actually, I'm not so sure about this anymore. Typically, new functionality
> has
> always been opt-in, instead of just there with the presence of the
> extension.
> This is to prevent behavior from changing on apps that were made before (or
> without knowledge of) the extension.. such as an app expecting the device
> enumeration string to remain constant across calls suddenly stops getting a
> constant string due to the presence of the extension which it
> didn't/couldn't
> account for.
>

I may be misinterpreting what you are saying here, but just to be
clear,  I think this is a problem that already exists in the current
implementation/spec of enumeration. To me, redectection is a perfectly
valid thing to do when asking for an enumeration list. Nothing says to
me that this should be static and any OpenAL implementation that
thought to do so could do redetection. (In fact, my patch does
redetection because it seemed perfectly reasonable.) Since the
Enumeration Extension is already just an extension and you wouldn't
get an enumeration list without it, and I don't think it made any
claims about being static, I'm not sure if the responsibility is
purely on OpenAL to protect existing apps that didn't account for
this. But certainly it would help for the spec to clarify this.


Finally, this is a question more for my curiosity than anything else.
I was wondering why OpenAL's design is so polling-oriented. There seem
to be many areas in OpenAL where some kind of function pointer
callback system would be really convenient. Buffer queuing/unqueuing
was one of those first areas that came to my mind. And now a device
removal callback seems like a good way to avoid needing to
continuously poll alGetError() for device removal.

Thanks,
Eric