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.
objarni's picture

Great news that AL is being integrated!

Please use same naming convention as the rest of OpenTK! My 2 cc.

Inertia's picture

OpenAL Status

OpenAL 1.1 bindings for AL, Alc and Alut including proper documentation were commited. Unit Tests went fine, except for the (experimental) XRam Extension class.

Some major refactoring happened, to please the established conventions. So the code i cited in this topic will currently not compile (will add a few book pages this week to give an introduction and proper examples).

Function overloads have been used to keep the number of options low, e.g. AL.SourcePlayv is an overload of AL.SourcePlay. Also AL.GetSourcefv, AL.GetSourcei, etc. are accessible as AL.GetSource.

What's next is porting all sample codes from the OpenAL SDK into C#, to a) verify full functionality b) debug the extensions c) put some OpenAL examples into the OpenTK tutorial launcher.

BIG FAT WARNING (tm) Fiddler

The Extension classes for XRam and EFX are highly experimental. If your sound card does not support these features, calling the Extension's methods is NOT recommended. You can safely compare the public bool IsInitialized to test if the Extension could be found when the constructor was called, before using the methods.

objarni's picture

Great news!

So is the first AL integration release 3.14 or 3.15?

the Fiddler's picture

Initial release == 0.3.14 as a work in progress.

A bugfix release will follow very soon, with openal updates, sample code etc.

Edit: Inertia, is there anything you think should hold up the release? OpenAL compiles and runs on all supported platforms; it's no problem if there are a couple of bugs hidden still, or some missing docs, we'll revise them in the next release.

I've merged the openal branch into trunk (don't like them drifting too far apart).

Inertia's picture

well, it needs some warning that the Extensions should be handled with care, but besides that i think the AL, Alc, Alut are ready for public release. No test programs crashed so far, all functions that could lead to memory leaks are currently disabled and the documentation is almost complete (needs one final pass to replace AL_TOKEN_NAME in the documentation with the new enums. This makes most sense to do when EFX is included aswell, because it adds some tokens into the existing enums.)

Which leads to another question:
Do you think the EFX stuff should be available as core functions? So far it seems the "Generic Software" and "Generic Hardware" drivers can both emulate EFX, even if the soundcard itself does not support it in hardware.
What EFX does is add a few more settings that can be attached to sources.
There's "Filter", "Effect" and "AuxiliaryEffectSlot" with 11 functions each. All 3 work similar to the other API functions, e.g.

void Efx.GenFilter()
void Efx.DeleteFilter()
bool Efx.IsFilter()
void Efx.Filter-f -i -fv -iv
void Efx.GetFilter-f -i -fv -iv

(replace "Filter" with "Effect" or "AuxiliaryEffectSlot" to get all 33 functions.)

Not sure, but maybe it would be best to revert the XRam class to my original approach (functions will early-out if the extension is not available) and stuff XRam and EFX into a single Extensions object, that can still be manually queried. It might be nice having the "Filter", "Effect" and "AuxiliaryEffectSlot" functions available directly in AL.

the Fiddler's picture

Ok, this is good enough for an initial release then. Everything else is ready, so I'll be releasing the new package on Sourceforge tonight. If you happen to do some small updates, (e.g. docs, bugfixes) direct them to the trunk - bigger things (efx) better stay in the branch for now.

Regarding extensions, how about following the approach of the GL class?

GL - contains the core functions
GL.Arb - contains Arb extensions
GL.Ext - contains Ext extensions
etc

AL, AL.Efx, AL.Xram?

Extension tokens added to vanilla AL enums would be marked as such in the inline documentation.

In any case it would be nice to keep delegates in a separate private class/namespace, and only add the 'wrappers' to the AL/Efx etc class. The reason for this is that it simplifies extension loading (iterate over all delegates in the separate class and call Alc.GetProcAddress).

Inertia's picture

EFX won't get finished today, there's alot of environment presets that belong to it too, which will probably take an afternoon alone to get right. If you don't mind, i'll rather update everything in the trunk to avoid running back and forth between branch and trunk. I didn't (will not) touch anything outside /trunk/Source/OpenTK/OpenAL (unless discussed 1st), and it'd be much simpler having 1 workdir to use.

Regarding extensions: AL.XRam, AL.Efx is what i had in mind, unless adding them directly to AL is the people's preference. It's pretty much how you define "core", the Efx stuff appears to work with both generic devices (and will most certainly work with native devices too), so it could be reasonable adding it as core functionality. (This must not be solved right now, just an observation)

the Fiddler's picture

The branch suggestion is just a measure to keep everything stable this close to release, and adding new extensions might be a cause of instability. Otherwise, no problem.

I'd define 'core' as anything that doesn't need GetProcAddress, extensions as everything that does. Agreed about AL.XRam etc.

Inertia's picture

won't commit any Efx.cs today, but in case something shows up in AL/Alc/Alut it would be best if i can commit the patch directly into the trunk, rather than starting confusion with the branch. (there are 0 known issues atm)

the Fiddler's picture

Agreed. I'll generate the packages for release now.