Inertia's picture

OpenAL 1.1

I've taken a closer look at the SDK, and so far it's easy to import the C functions into C#. I've done the whole Alc.h header file and wrote a little test app to query devices/strings/ints/etc. and it seems to work fine with the "SB Live! Wave Device".

My question is now: Is there anyone working on OpenTK.OpenAL already? It was just an exercise to see if I can do it, and if this is already WIP by someone more experienced with importing, i'll just put it into the archive and forget about it.
If there hasn't been any work done for this, I'd continue porting FreeAlut.h and Al.h to C# too, but the Al portion is rather large and I don't want to do this if it's already addressed by someone else. It's not so much the import that's the issue, it's the quantity of documentation for the functions.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Inertia's picture

There has been a discussion on IRC yesterday regarding helpers in OpenAL, and some feedback from the users would be greatly appreciated. Some helpers were already added to be consistent with the OpenGL API, you might not have noticed it though because it felt "natural" when you are used to writing OpenTK.OpenGL programs: AL.Gen[Object]() and Al.Delete[Object]() overloads, that accept a single Handle.

A new helper that was discussed would be AL.BindBuffer(). What this does is simplify the common task of attaching a Buffer to a Source, very similar to what GL.BindTexture() does.
This function is not part of the native OpenAL API though, and people might get confused that there is no reference to it in the C documentation.

The question is now: Would you appreciate such helpers (assuming they are properly documented in the inline documentation and OpenTK reference manual at http://www.opentk.com/doc/ref ), or would this be more confusing than helping?

It is not intended the replace the original approach of the API, it would just add a more elegant and OpenGL-like option to accomplish the same task.

uint MySource, MyBuffer;
 
AL.Source( MySource, ALSourcei.Buffer, (int) MyBuffer);
vs.
AL.BindBuffer( MySource, MyBuffer );

Is the name BindBuffer confusing? should it rather be AL.BindBufferToSource? or AL.SourceBind?

Opinions would be very much appreciated, because this is something that should better not be changed once added. Thanks!

Inertia's picture

Update:

OpenAL bindings for the Efx Extensions were commited to SVN at the weekend. Fiddler has been working on the AudioContext wrapper, which will probably be included in the next OpenTK release aswell.

The question in my last post still applies, if you have a clear preference you should voice it now, before the next release. My current tendency is:

AL.BindBufferToSource
Efx.BindFilterToSource
Efx.BindEffectToAuxiliarySlot
Efx.BindSourceToAuxiliarySlot (implies attaching optional Filter in parameters)

This should help finding all these helpers under AL.Bind* (which is unused by the OpenAL API), and is rather verbose what exactly the helper does. It will NOT replace the standard way to do these operations, it is just a more elegant way to use the underlying commands to achieve the same.

On a sidenote, creative labs have been contacted regarding some legal issue of the Efx Presets (you can imagine this as a database of pre-defined environments, like different room-sizes in a castle/factory/cave, used to simulate correct acoustics). There has not been a clear reply yet, (and I doubt they'll make any trouble) but if they cooperate with the request, OpenTK.OpenAL will be the most complete managed AL bindings available to the .Net environment. (trying to be optimistic here, don't spoil it :p)

Inertia's picture

Update:

Creative Labs have been very helpful and patient answering questions (thank you!) and in OpenTK 0.9.1 the OpenAL part will be moved from alpha to beta. It's feature-complete, no known issues (which couldn't be fixed by installing the latest OpenAL drivers for linux) and the only things that need some more care are the EfxReverb presets, and minor documentation improvements.