Jump to content
  • Advertisement
Sign in to follow this  
Starfox

An OpenAL DSP-based audio shading effects language

This topic is 4484 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

If you've been using OpenAL, you'll have noticed that the only way of having real time audio effects are via either the EAX Extensions (which have nothing to do with the design methodology of OpenAL, if I may rant) or the recently introduced EFX Extensions. Before EFX was out, I've been working on a DSP like shading system that's sort of OpenAL meets GL_ARB_fragment_program (keep reading, if you're not an OpenGL buff, everything will be clearer a few lines down). Mainly, I wanted to break from the fixed set of EAX, and since even relatively old sound boards have decent DSPs (see the Kx project for some amazing utilization of the Emu10K chips), that should be possible in real time. Seeing as I knew nothing about audio programming, I turned to friend and GameDev member Jonathan "LoneSock" Dummer to help me with this. We eventually came with a framework for a "proposed" OpenAL source shaders extension. It mainly allows you to write small assembly language programs (for now, a high level compiler is coming soon) that execute on OpenAL Sources. I have created a wrapper DLL that adds support for this extension (albeit in software, amazingly slow for now) with the help of a friend and coworker of mine, Hisham H. Fawzy (Credit given when due, he did the wrapper framework, and a handy parser for overriding existing AL funcitons :) ). We created 2 new extensions: AL_TWX_asm_shader_objects and AL_TWX_source_shader_asm (extensive documentation coming soon, for now, check the ALEXT header supplied below and the sample application). To get started, here're the files we have about this, publicly available online: 1) A replacement wrap_oal.dll (IMPORTANT: READ THE SECTION CALLED INSTALLATION NOTES, FURTHER DOWN, BEFORE DOING ANYTHING WITH THIS FILE). 2) A header file for the extensions, alext.h 3) A sample application that uses the extensions, along with a mono wav file and a couple of shaders: ALSL_Sample.rar 4) A quick reference document, for the extension instructions and registers: alasm_ref.txt INSTALLATION NOTES: 1) Download the latest OpenAL installer from OpenAL.org 2) Run the installer (D-U-H!) 3) Go to the windows/system32 dir 4) Rename wrap_oal.dll to oal_icd.dll 5) Copy our wrap_oal.dll to the system32 dir, and you're done. You can run the binary available with the ALSL Sample rar, the command line parameters are: alsl.exe <wav file> <shader file> Keep in mind that the modified DLL will dump the processed results in a wav file in the same directory as the application using it, so that you can check it with any audio viewer (we use Audacity). Credits go to Jonathan for the wave writing function. Let me know if you need any more info, make suggestions, etc. We hope to get this in a mature enough form to warrant IHV support, and any help would be appreciated. For bug reports, additional instructions requests or if you need to talk more privately, feel free to email me directly: sherief 'at' mganin.com Please try to share your shaders, as they'll help everyone learn, innovate, and show the world how buggy my code really is :D :D .

Share this post


Link to post
Share on other sites
Advertisement
I was just thinking, this might be better under either the "Alternative Game Libraries" or the "Music and Sound" forums. Would a moderator mind moving this?

thanks [8^)

Share this post


Link to post
Share on other sites
Er... OK, OpenAL is covered under alternative game libraries, sorry.

Mods: would someone please move this post?

Share this post


Link to post
Share on other sites
Very cool. It seems like everything these days is moving towards less fixed function and more programability. If you've read anything on on those new soundblaster X-Fi cards, they're basically a ton of DSP power, something like 100x the computing power of the previous Audigy generation, and the higher end ones even have 64 megs of onboard RAM. These kinds of 'Sound Shaders' would be awsome on the appropriate hardware. You may also want to check out the Khronos Group's OpenSL (Open Sound Library) though I don't know if there's even a public draft available yet.

Share this post


Link to post
Share on other sites
Exactly. X-Fi cards have TONS of unused power. Our goal is to get a spec out and have it eventually supported by IHVs, but the lack of an OpenAL ARB made us a little puzzled about where to start, so we thought to provide an example :D.

I'm currently working on a GLSL like high level language and compiler for the effects (calling it ALSL, to keep after the design tradition ;) ).

Let me know any suggestions/ideas you have.

Share this post


Link to post
Share on other sites
Being a voting AES member, and a former music-DSP junkie, I totally agree with shader capabilities for sound card DSPs.

When it comes to sound DSP, though, you often find that storage is not strictly linear, like in regular CPUs, but might instead come in sets of filter banks and delay lines etc (used for reverbs, delays, flanges, etc). Given that each architecture has a different memory structure, it becomes harder to generate a standard shader language.

On the up-side, the emu10k line (all the Creative cards these days) seems to pretty much dominate anyway.

Something that would be useful would be to be able to describe the effect you want as a sequence of delay lines and IIR filters (with mixing). That's a little closer to how audio engineers typically work, and would map to more exotic kinds of hardware.

To support various non-linear effects (compressors, etc), you probably need some kind of conditional, such as set-if-greater etc.

Last, you might want to think about how a programmer could express an FFT in this language. Lots of interesting effects (long convolutions, etc) are done in FFT space.

Share this post


Link to post
Share on other sites
Mind elaborating a bit? I'm looking into FFT, I'd like to know what conditionals do you need and how do you want them to act. I'm trying to make this map as closely as possible to the Emu10K1 chip's capabilities, so that a hardware implementation could be possible.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!