[Openal] Q on device hot-plug

[Michel Donais]

FWIW, we are planning on using the tool for a very large audience game
that's scheduled in the following months. What we'll be doing is opening
MMSystem and monitor what's happening, and if we see our current devices
disappearing, we'll show a message to the user to select a new one, and if
we see a new device appearing, we'll show a message telling the user if he
wishes to use it, he needs to restart the game (and offer him the choice to
do so immediately). For me, that's what I'm trying to avoid.


=== SNIP ===
This is what I would personally add (written in this e-mail so I'm writing
very quickly here) as extension. If you don't care, go to end of snip.

My personal hunch is as follows:
- By default, OpenAL's behaviour should tend on leniency.
	- A new device being connected shouldn't change the currently
connected devices.
	- An old device being disconnected should still appear and exist,
and it should be able to be opened.
	- A currently opened device that's disconnected when starting (or
being disconnected) shouldn't crash the system, as by default there isn't a
way for the software to know it has been disconnected. It should return
empty values when queried.
	- The device being reconnected, it should resume working.

- By having one command updating the values in a second internal named
buffers.

- By having one command returning the updated version of the device list, it
is then easy for the user to do its own parsing, see what is different, see
what has been added, modified, and so on. For example, getting the string
list "updated all playback devices", would return a new version that would
only be viable until the next update in the values. These wouldn't be
accessible for now.

- By having one command acknowledging these new values, in both ALL and
"normal" extensions, as well as the default interface, including "Capture"
devices. That would effectively clear up the previous values, and would
update what's retrieved by the getString for everything, making a the
original values hazardous to use (potential crash), but making the new
interfaces accessible.

- Even by acknowledging a new interface, opened devices shouldn't modify
their behaviours, if a device is still open after acknowledging, it should
not crash and still be accessible (see tend on leniency).

- For me, everything should be polled, I am not a believer the user will see
the value of the game as degraded if he doesn't have sound for 5 seconds
after he disconnected his speakers. Whenever my game wishes to update the
values, it can update, check for differences, and then acknowledge whenever
it wishes to apply changes.

Example (pseudo-C++ code):
	OpenAL al;
	DeviceList playback(al, ALC_DEVICE_SPECIFIER);
	DeviceList capture(al, ALC_CAPTURE_DEVICE_SPECIFIER);
	if (al.alcIsExtensionPresent(NULL, "ALC_UPDATE_ENUMERATIONS_EXT"))
		while (true)
		{
			al.alcGetIntegerv(NULL, ALC_UPDATE_ENUMERATIONS, 0,
NULL);
			DeviceList newPlayback(al,
ALC_UPDATED_DEVICE_SPECIFIER);
			DeviceList newCapture(al,
ALC_UPDATED_CAPTURE_DEVICE_SPECIFIER);
			ComparisonResult result =
newPlayback.compare(playback) && newCapture.compare(capture);
			if (result)
			{
				al.alcGetIntegerv(NULL,
ALC_ACKNOWLEDGE_UPDATED_ENUMERATIONS, 0, NULL);
				// at this point, playback and capture
contains invalid pointers to OpenAL
				playback.update();
				capture.update();
			}
		}

Q&A:
- Can I use the names as shown in ALC_UPDATED_DEVICE_SPECIFIERS? Yes. You do
not need to retrieve them again in ALC_DEVICE_SPECIFIER. However, that
pointer contains volatile data, and you must do a personal copy if you wish
to keep on using it. The other possibility is to get them again inside
ALC_DEVICE_SPECIFIER once updated.
- Can I use a device in the updated list, or do I need to acknowledge? You
need to acknowledge. The list is not valid until acknowledgement by OpenAL's
standard tools is done.
- What is updated when I ask update? Everything that got the UPDATED flag.
Including DEFAULT devices, ALL device enumerations.
- What happens if I do not update prior to retrieving updated versions?
Unsupported. Potential crash, empty list, undefined variables.
- Can I get multiple times the same values between updates? Yes. They are
only updated once the Update is done.
- What happens if a new device appears or disappears after an update? It
will not be registered by the system.
- What happens if I acknowledge a device that was deleted between an update
and acknowledgement? The device will still exist in OpenAL. It becomes the
same as a device disappearing after OpenAL is first loaded, but disappearing
before opening the device: it is still shown in the list of accessible
devices.


Now ... For clarity, that is what I have in my mind. So any suggestion given
to me will be thrown against what I'm actually looking for, and what's
roughly explained in this e-mail.

=== /SNIP ===

- I don't like the extension being called Disconnect when it can actually
connect elements.
- I don't like the idea once you acknowledge the ability to disconnect, that
a device can actually make the game crash.
- I don't like of automatically switching from one system to the other, or
to change the behaviour of OpenAL according to an extension or a lack
thereof.
- Multithreading stipulates any action will happen in one assembly
instruction. So having to call ALC_CONNECTED all the time before one frame
to see if my device is zombified means it will still happen between two
instructions. I have a tendency to err on leniency, to call this function
every now and then, and having it return me an informal value, instead of
something I must act upon immediately. For example, if I got a audio
rendering thread, a audio capture thread and a UI thread, I would probably
make the rendering go as fast as possible, the capture go as fast as
possible, and the UI calling the ALC_CONNECTED extension once in a while.
Once UI determines the device is disconnected, I would sent an event to the
threads to tell them "hey guys, stop rendering, your device is pooped". In
the meantime, it should still work adequately.

Otherwise, this extension would still suit my needs.



-----Message d'origine-----
De : openal-bounces at opensource.creative.com
[mailto:openal-bounces at opensource.creative.com] De la part de
openal-request at opensource.creative.com
Envoyé : 12 août 2009 15:00
À : openal at opensource.creative.com
Objet : Openal Digest, Vol 41, Issue 5

Date: Wed, 12 Aug 2009 08:28:49 -0700
From: Chris Robinson <chris.kcat at gmail.com>
Subject: Re: [Openal] Q on device hot-plug	
To: openal at opensource.creative.com
Message-ID: <200908120828.49764.chris.kcat at gmail.com>
Content-Type: Text/Plain;  charset="iso-8859-15"

On Tuesday 11 August 2009 2:06:29 pm Michel Donais wrote:
> We are creating casual gaming products, and for us, the ability to connect
> a microphone or a USB headphones/microphone combo while the app is running
> is nearly primordial. Most people in our audience don't keep these
> connected at all times. They usually refrain from connecting the device
> until the last minute.
>
>
>
> I'd love to have a standardized way to be able to  detect such connections
> / disconnections, and then react accordingly. I first thought getting the
> strings would give me proper info, but I guess it doesn't. And I do
> understand why you wouldn't want to change these strings, however, that'd
> be my best tool. And even if I detected these changes outside of OpenAL, I
> don't have a way to reinitialize OpenAL to acknowledge such changes.

Hi.

There was a proposal for an extension to detect when devices are
disconnected 
and to update the device list with new devices:

http://icculus.org/alextreg/wiki/ALC_EXT_disconnect

Unfortunately it's still not implemented. It may be a good idea to discuss
it 
again, if we're going to be talking about OpenAL 1.2.

FWIW, I only have two issues with the extension:

I don't think it's necessary to specify the behavior of alcOpenDevice(NULL),

as in question 3, as that's implementation/system behavior that is not
really 
affected by this extension. OSX already does it without this extension, and 
having this extension doesn't guarantee that behavior.

And I don't like the idea of the enumeration strings only being valid until 
the next query for them. IMO, the enumerations should change only when the
app 
calls something new, so existing behavior won't be changed and risk breaking

apps that rely on it.