[Openal-devel] Three Extensions

[Chris Robinson]

On Monday 23 February 2009 4:40:17 am Richard Furse wrote:
> Hi there - I'm getting close to releasing a new software Ambisonic OpenAL
> implementation (it was demoed at the recent AES games conference) I've
> added some extensions and I thought I should present them for comment here
> before registering them with the database.

Hi. Good to see another OpenAL implementation springing up. :)

> The extensions are:
> *	AL_EXT_FOLDBACK (see al-foldback.h, enclosed) is an extension to
> allow a mixdown of the game's audio to be fed back to the game in mono or
> stereo.

Render-to-buffer (or generally some way to render so that an app can read back 
into a buffer), has been requested for some time. Unfortunately, given the 
asynchronous, real-time nature of OpenAL, it's a bit difficult to come up with 
a method that's efficient enough, simple to handle, and flexible.

The main thing that strikes me about this proposal is the use of a callback. 
I'm not sure this is very flexible or simple  with language bindings. 
Considering neither OpenAL nor OpenGL have callbacks anywhere in its core API, 
I would assume this is because of portability concerns.

Maybe some kind of query mechanism would work better? eg. Set up an query to 
watch for 'foldback events', which can be retrieved when one is available. The 
events would be polled by the app instead of a callback being called.


Perhaps also, instead of writing to user memory, it can write to a buffer 
queue. The user queues up a certain amount of buffers then calls 
alRequestFoldbackStart. When an AL_FOLDBACK_EVENT_BLOCK event occurs, the 
buffer can be unqueued, and another buffer can be queued to keep it going 
(similar to how source buffer queues work, except its for writing instead of 
reading). If the queue ever becomes exhausted, it automatically stops and 
sends the appropriate event.

Should the data be needed in user memory, AL buffers can be given an 
alGetBufferData function to retrieve it. eg:
if(event == AL_FOLDBACK_EVENT_BLOCK)
{
    alFoldbackUqueueBuffers(1, &bID);
    alGetBufferData(bID, format, freq, datalen, data);
    alFoldbackQueueBuffers(1, &bID);
}


I'm imagining that in addition to simply recording what you hear, an app can 
create a "playback-less context" with a special context creation flag. An app 
would use that context exclusively for foldback operations, and the buffers 
would be shared with the playing context on the same device. This would allow 
you to render a completely different environment than what's being heard by 
the player.

> *	Two new effects (AL_EFFECT_DEDICATED_LOW_FREQUENCY_EFFECT and
> AL_EFFECT_DEDICATED_DIALOGUE, see efx-dedicated.h) to route audio directly
> to LFE or centre speakers where present.

I think these would work better as explicit buffer formats:
AL_FORMAT_LFE[8|16|32]
AL_FORMAT_CENTER[8|16|32]

Or maybe some kind of buffer flag..
alBufferi(bID, AL_MONO_TO_CENTER, AL_TRUE);
// or
alBufferi(bID, AL_MONO_TO_LFE, AL_TRUE);
The buffer would be treated as multichannel (in that it doesn't get 
spatialized and may not get sent through the source sends), and would have no 
effect if the buffer data is multichannel.

> *	AL_EXT_BFORMAT (see al-bformat.h) allows multichannel buffers to of
> first order Ambisonic B-Format data. This extension also implies the
> ability to re-orient these buffers via alSourcefv() and alListenerfv().

Can't say much about this since I'm not very familiar with Ambisonic. I assume 
you need both an 'at' and 'up' vector for sources, not just 'at'? Perhaps this 
can be generalized so that all sources can accept AL_ORIENTATION, but allowing 
for the 'up' vector to be ignored. Setting a source's AL_ORIENTATION would 
overwrite its AL_DIRECTION with the given at-vector, and setting a source's 
AL_DIRECTION would overwrite the at-vector and leave the up-vector undefined.