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

[E. Wing]

On 12/30/08, Chris Robinson <chris.kcat at gmail.com> wrote:
> FWIW, I fully agree with your assessment about the need for proper
> enumeration
> on systems that have multiple input/output devices. It kinda defeats the
> purpose of enumeration if all you can do is select the default choice.
>
> Unfortunately though, I'm not a Mac developer, so there's nothing I can
> directly do about it (at least until OpenAL Soft properly supports OSX)..
> just voice my support for proper enumeration.

Thanks, I appreciate your support. If you have time to kill and don't
mind free registrations, you could still file a bug on the Apple
radar. I suspect they will just toss it, but maybe they'll add it to
the tally.


> There are a couple points I want to respond to in your email, though..
>
>> I also double-null-terminate
>> individual/specific device queries since that is what the current
>> implementation does even though the 1.1 spec says nothing about this.
>
> The double-null termination is called for by the spec, actually. It's how
> the
> list is terminated.

> 9.5. ALC_ENUMERATION_EXT on page 62 of the spec:
> "Each device name will be separated by a single NULL character and the list
> will be terminated with two NULL characters."
>

Yes, but I wasn't talking about lists in this case. I was talking
about specific device queries.

So this is an enumeration query that requires a double-null-terminator
according to the Spec:
list_of_devices = alcGetString(NULL, ALC_CAPTURE_DEVICE_SPECIFIER);

But this is a single device query and the Spec doesn't say anything
about double-null-terminators:
device_name = alcGetString(captureDevice, ALC_CAPTURE_DEVICE_SPECIFIER);

It happens that the current Apple implementation does the exact same
thing in both cases and returns only the default device name with a
double-null-terminator. So to preserve compatibility, I made sure to
return the double-null-terminator in both cases, even though the spec
says nothing about the latter.



>
>> (By the way, this might also suggest a need for another OpenAL
>> extension. This suggests there is a distinction between a unique
>> identifier and a human-readable localized device description.)
>
> AFAIK, the device desciption is intended to be the identifier. The
> implementation is allowed to append things to device names to make sure it
> is
> unique (so long as it accepts the modified string, of course).

So there is unfortunately a distinction between human identifiers and
unique identifiers. To me, the spec itself doesn't really seem to make
the distinction, though implicitly with the current API things are
guaranteed to work correctly if unique identifiers are used and not so
if they aren't. The problem is unique identifiers are not always human
friendly, e.g. a MAC address on an ethernet card.

But I was thinking about the problem a little bit after my post
yesterday, and I came up with an idea like yours. I think your idea
might be the best way to deal with the issue. The only problem I see
with it is if the device order changes for some reason, the program
might get confused. (Maybe the user is unplugging/replugging devices
and not in the same order and simple de-ambiguity markers you add
(e.g. #2, #3, #4), might cause things to not appear as they were
before.) But it's probably not a serious problem.

But maybe this is all moot. Maybe Core Audio already makes device
names unique. I don't know Core Audio well enough to say. And I don't
have the devices to test this. (Though my 3rd party iMic shows the
same name for capture and output, but this one isn't really a direct
conflict since input/output are treated separately.)

Thanks,
Eric