Bug in ALUT_WAVEFORM_SINE?

[Dave Dribin]

Hi,

I was looking through the code that generates a sine wave, and I think  
it's incorrect.  The [0..+1) phase should be multiplied by 2*pi not  
pi, right?

-Dave

----

Index: alut/src/alutWaveform.c
===================================================================
--- alut/src/alutWaveform.c (revision 1622)
+++ alut/src/alutWaveform.c (working copy)
@@ -20,7 +20,7 @@
  waveformSine (double UNUSED (lastPhase), double phase)
  {
    static const double pi = 3.14159265358979323846;
-  return sin (phase * pi);
+  return sin (phase * 2 * pi);
  }

  static double

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Richard Furse-2]

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.

<<...>> <<...>> <<...>>
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.
• 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.
• 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().

Please let me know what you think!

Best wishes,

--Richard

#ifndef AL_AL_BFORMAT_H
#define AL_AL_BFORMAT_H

// PROVISIONAL
//
// THIS HAS NOT YET BEEN REGISTERED IN THE OPENAL EXTENSION DATABASE
// OR SETTLED FOR ANY REAL USE AS YET.

/*
 * This extension indicates support for the AL_FORMAT_BFORMAT8,
 * AL_FORMAT_BFORMAT16 and AL_FORMAT_BFORMAT_FLOAT32 buffer formats.
 *
 * These are, respectively, 8bit int, 16bit int and ALfloat support
 * for Ambisonic four-channel B-Format (using W X Y Z channel
 * ordering, encoded as the first four channels of Furse-Malham higher
 * order Ambisonics). Use of these formats indicate that sources are
 * Ambisonic sources. Such sources can be oriented via alSourcefv()
 * using the AL_ORIENTATION tag, which takes the same parameters as
 * the alListenerfv(AL_ORIENTATION,...). Such sources DO support
 * AL_SOURCE_RELATIVE and the soundfield will rotate to reflect the
 * listener's orientation if this is off (the default). Other
 * behaviour is as for stereo or multichannel assets.
 *
 * Note that Ambisonics orients X, Y and Z axes in a different way to
 * OpenAL. For clarity, we ignore the Ambisonic coordinate system in
 * the API and stick to the OpenAL one, making sure that the Front of
 * the Ambisonic soundfield (actually Ambisonic +X) matches the Front
 * of the OpenAL coordinate system (-Z by default) etc. For instance,
 * if the orientation of the source is set so that the "at" vector is
 * to the left, then the front of the B-Format soundfield will be
 * presented to the left.
 */
#define AL_EXT_BFORMAT_NAME "AL_EXT_BFORMAT"

#define AL_FORMAT_BFORMAT8            0x20001
#define AL_FORMAT_BFORMAT16           0x20002
#define AL_FORMAT_BFORMAT_FLOAT32     0x20003

#endif /* AL_AL_BFORMAT_H */

#ifndef AL_AL_FOLDBACK_H
#define AL_AL_FOLDBACK_H

// PROVISIONAL
//
// THIS HAS NOT YET BEEN REGISTERED IN THE OPENAL EXTENSION DATABASE
// OR SETTLED FOR ANY REAL USE AS YET.

#include "al.h"

#if defined(__cplusplus)
extern "C" {
#endif

#define AL_EXT_FOLDBACK_NAME "AL_EXT_FOLDBACK"

#define AL_FOLDBACK_MODE_MONO   0x4101
#define AL_FOLDBACK_MODE_STEREO 0x4102

#define AL_FOLDBACK_EVENT_START 0x4111
#define AL_FOLDBACK_EVENT_BLOCK 0x4112
#define AL_FOLDBACK_EVENT_STOP  0x4113

/**
 * Foldback Notes:
 *
 * This OpenAL extension provides a "foldback" facility to OpenAL,
 * allowing a mono or stereo mix of the overall OpenAL output to be
 * fed back to the originating software for further processing,
 * recording etc.
 *
 * The OpenAL extension can be detected by a call to
 * alIsExtensionPresent requesting extension "AL_EXT_FOLDBACK"
 * (defined by macro AL_EXT_FOLDBACK_NAME).
 *
 * If it is present, the calls "alRequestFoldbackStart" (of type
 * LPALREQUESTFOLDBACKSTART) and "alRequestFoldbackStop" (of type
 * LPALREQUESTFOLDBACKSTOP) will be available from
 * alGetProcAddress. Both of these calls are asynchronous and start an
 * event stream to be handled by a callback function required by
 * alRequestFoldbackStart.
 *
 * The calling software is required to provide a range of memory into
 * which foldback data will be written. This range of memory is a
 * circular buffer, divided into fixed-size blocks. Data is
 * interleaved if stereo is required. The callback function indicates
 * when a block of memory is ready for processing. The callbacks are
 * delivered asynchronously and in sequence - it is up to the calling
 * software to keep up with the data flow.
 *
 * If the alRequestFoldbackStart call succeeds, the callback function
 * will be fed events. The first event is an AL_FOLDBACK_EVENT_START
 * event indicating that streaming has begun. Subsequent events are
 * zero or more AL_FOLDBACK_EVENT_BLOCK events indicating each block
 * as it becomes ready, with a final AL_FOLDBACK_EVENT_STOP to
 * indicate that processing has ended. The memory region should not be
 * released until an AL_FOLDBACK_EVENT_STOP event has been received
 * (normally this occurs after alRequestFoldbackStop has returned).
 */

/**
 * Foldback Callback.
 *
 * Three different "event" values are defined: AL_FOLDBACK_EVENT_START
 * indicates that streaming has begun, AL_FOLDBACK_EVENT_BLOCK
 * indicates a data block is ready and AL_FOLDBACK_EVENT_STOP
 * indicates that streaming has ended.
 *
 * The "blockIndex" value is defined only where the event is
 * AL_FOLDBACK_EVENT_BLOCK. In this context, it indicates which block
 * (indexed from zero) within the memory region provided to
 * alRequestFoldbackStart is ready. Note that the blockIndex value
 * wraps around, returning to zero when the bufferCount is reached.
 */
typedef void (AL_APIENTRY *LPALFOLDBACKCALLBACK) ( ALenum event, ALsizei blockIndex );
 
/**
 * Function name: alRequestFoldbackStart
 *
 * If this call succeeds, then it is guaranteed that the callback
 * function be called at least once with a start event and once with a
 * stop event.
 *
 * If this call sets AL_INVALID_VALUE, this may be because the
 * blockCount and blockLength are not large enough for the current
 * renderer, so it may be worth trying a larger value.
 *
 * Data is written into the region of memory starting at bufferMemory
 * in sequential blocks of floats of length blockLength, or twice
 * blockLength if stereo is used (data is interleaved). After each
 * block is written, a callback is queued for delivery.
 *
 * "foldbackMode" may be AL_FOLDBACK_MODE_MONO for mono or
 * AL_FOLDBACK_MODE_STEREO for interleaved stereo.
 *
 * "blockCount" indicates the number of blocks of audio that should
 * be available at bufferMemory. This must be at least two.
 *
 * "blockLength" indicates the number of frames of audio that should
 * be available within each block. Note that there will be two samples
 * per frame if stereo is in use.
 *
 * "bufferMemory" indicates the start of the region of memory,
 * provided by the calling software, which will be used for the shared
 * circular buffer. It is required to allow space for a number of
 * floats: blockLength*blockCount floats if foldbackMode is
 * AL_FOLDBACK_MODE_MONO or blockLength*2*blockCount floats if
 * foldbackMode is AL_FOLDBACK_MODE_STEREO. The memory is owned by the
 * calling software and should not be deleted until an
 * AL_FOLDBACK_EVENT_STOP event has been received.
 *
 * "callback" is the pointer to a function provided by the calling
 * software that will handle foldback streaming events (see above).
 */
typedef void (AL_APIENTRY *LPALREQUESTFOLDBACKSTART) ( ALenum foldbackMode, ALsizei blockCount, ALsizei blockLength, ALfloat * bufferMemory, LPALFOLDBACKCALLBACK callback );
/**
 * Function name: alRequestFoldbackStop
 *
 * This call requests an end to foldback.
 *
 * Note that this call does not stop foldback immediately - any queued
 * blocks must still be processed. A stop event
 * (AL_FOLDBACK_EVENT_STOP) will be received to indicate that the
 * foldback has actually completed and buffer memory should not be
 * freed before then.
 */
typedef void (AL_APIENTRY *LPALREQUESTFOLDBACKSTOP) ( void );

#if defined(__cplusplus)
}  /* extern "C" */
#endif

#endif /* AL_AL_FOLDBACK_H */

#ifndef AL_EFX_DEDICATED_H
#define AL_EFX_DEDICATED_H

// PROVISIONAL
//
// THIS HAS NOT YET BEEN REGISTERED IN THE OPENAL EXTENSION DATABASE
// OR SETTLED FOR ANY REAL USE AS YET.

/*
 * Audio rendered to this effect is routed to a subwoofer if one is
 * present. Otherwise, it is discarded.
 */
#define AL_EFFECT_DEDICATED_LOW_FREQUENCY_EFFECT 0x9000

/*
 * Audio rendered to this effect is routed to a front centre
 * speaker if one is present. Otherwise, it is rendered to the
 * front centre using the normal spatialisation logic.
 */
#define AL_EFFECT_DEDICATED_DIALOGUE             0x9001

#endif /* AL_EFX_DEDICATED_H */

_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

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.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Richard Furse-2]

> -----Original Message-----
> From: openal-devel-bounces@...
> [mailto:openal-devel-bounces@...] On
> Behalf Of Chris Robinson
> Sent: 23 February 2009 14:50
> To: openal-devel@...
> Subject: Re: [Openal-devel] Three Extensions
>
> 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. :)

Thanks :-)

It's called "Rapture3D".

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

I guess I've gone for simple and efficient, but not 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.

Yep - I considered this, but came to the conclusion it was best to notify
the app, in the style of most other inbound APIs. This keeps thread sync
really simple. If the app really can't cope with the language binding (is
there really much stuff not in C/C++?) we could always shove a standard
callback implementation in ALUT to store the callbacks and list them back on
request.

> 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);
> }

Yep, I can see that would work and is more elegant in many ways, though
there are quite a few moving parts and it would probably be quite a bit of
work to do right.
 

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

Ooo. That's rather interesting, though it might need some work to make sure
we didn't end up inducing a lot of overall latency.

Let me know if you're planning to code up something like this - perhaps we
could coordinate to make sure we've consistent implementations.

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

Yup, that would work.

However, we've gone the effect route as it allows the game to choose to
boost the LFE of something that's already playing.

> > * 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'?

Yep, this is exactly what we've done, hence the use of AL_ORIENTATION.

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

Interesting... I guess most games wouldn't NEED this as they'll know which
of their sources are in B-Format, but it would be very easy to add.

Thanks!

--Richard


_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Stephen A.]

Την Mon, 23 Feb 2009 17:55:08 +0200,ο(η) Richard Furse  
<rf015d9821@...> έγραψε:

>>
>> 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.
>
> Yep - I considered this, but came to the conclusion it was best to notify
> the app, in the style of most other inbound APIs. This keeps thread sync
> really simple. If the app really can't cope with the language binding (is
> there really much stuff not in C/C++?) we could always shove a standard
> callback implementation in ALUT to store the callbacks and list them  
> back on
> request.

Just pitching in to say that yes, there's a lot of openal stuff out there  
that's not C/C++.

In my experience (a library called opentk with C# bindings to opengl,  
openal and opencl), callbacks are the single biggest issue. Oftentimes,  
the only way to make them work is to write a C/C++ layer that abstracts  
the callback.

So please avoid callbacks, if at all possible :)
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel

[Chris Robinson-5]

On Monday 23 February 2009 7:55:08 am Richard Furse wrote:

> > 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.
>
> Yep - I considered this, but came to the conclusion it was best to notify
> the app, in the style of most other inbound APIs. This keeps thread sync
> really simple.

It would actually make it more difficult, because if the capturing/rendering
is done asynchronously, the callback would be called asynchronously. As such,
the user would be responsible for keeping thread safety. It would also make
things difficult because of the internal locks going on that the user app has
no idea about, and the sensitive timing needed to get the rendered data out to
the sound device. The safest thing for an app to do would be to just set a
flag to check later..

> If the app really can't cope with the language binding (is
> there really much stuff not in C/C++?) we could always shove a standard
> callback implementation in ALUT to store the callbacks and list them back
> on request.

At the very least, a user data handle will be needed so the bindings can store
the needed info for calling between the wrapper callback and the real user
function. But I think it's better left alone than to try it this way.

> > 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);
> > }
>
> Yep, I can see that would work and is more elegant in many ways, though
> there are quite a few moving parts and it would probably be quite a bit of
> work to do right.

A bit more work, but you get a bunch of flexibility in return.

> > 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.
>
> Ooo. That's rather interesting, though it might need some work to make sure
> we didn't end up inducing a lot of overall latency.

That's another benefit of keeping it in AL buffers. It can all be done
asynchronously without having to push data around. It can write to the same
memory segment that's read from, which doesn't even need to be in system RAM.
All you do is get the event that the buffer is complete, then you remove it
from one queue and put it in another.

> Let me know if you're planning to code up something like this - perhaps we
> could coordinate to make sure we've consistent implementations.

There could be an issue with how to actually do the render. In OpenAL Soft, a
user can set 5.1 or 7.1 output.. but since the foldback can only take mono or
stereo, it requires additional re-channeling. Not a huge deal, but something
that may need consideration.

Also, there's a question of how to split it up. I don't think a render-to-
buffer extension would be the best place to introduce an alGetBufferData
function (since it's perfectly usable without requiring an implementation to
handle render-to-buffer). But if it's going to be its own extension, there's
other buffer-related things that can be added, too.. for example, the number
of sample frames/length in time is something I would find useful). The query
stuff could also be done generically, so it can be reused with other
extensions.

> However, we've gone the effect route as it allows the game to choose to
> boost the LFE of something that's already playing.

If you use an effect to feed data into the center or lfe channel, you could
also lose the ability to have another effect going at the same time. OpenAL
Soft and Creative's software driver both allow you to create only one effect
slot, so if you have a mono-to-center effect set on the slot for a narrative,
you can't apply reverb to any other sources that may be playing. You couldn't
even apply a mono-to-lfe effect on another source.

A buffer or source attribute wouldn't have that problem. It wouldn't even
require EFX. If it's a source attribute, the same buffer can be used on two
sources.. one that maps it to LFE, and one that plays it normally.

> > 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.
>
> Interesting... I guess most games wouldn't NEED this as they'll know which
> of their sources are in B-Format, but it would be very easy to add.

Yeah. The main thing is AL_ORIENTATION being valid only if a B-Format buffer
is being used. Since a source already uses half of the orientation data, I
don't see why it couldn't just use it regardless of the format. If your app is
"B-Format aware", then you can just use AL_ORIENTATION and forget about
AL_DIRECTION; and "B-Format unaware" apps can use AL_DIRECTION without a
problem since only B-Format buffers will use the up-vector.
_______________________________________________
Openal-devel mailing list
Openal-devel@...
http://opensource.creative.com/mailman/listinfo/openal-devel