OpenAL Audio Library



What is this?

This is my hardware accelerated version of OpenAL for Linux. It requires a Soundblaster Live or Audigy and ALSA.


6 Jul 2004

Another possible problem that some people may be having is a bug in NPTL. I don't have NPTL installed, just LinuxThreads.

2 Jul 2004

If you have an Audigy and are getting sound from the rear speakers but not the from try editing alc_speaker.c; In the array audigy_send_routing change every "8, 9" to "0, 1". The caveat at the end of the top level README will then defiantly apply. If this works please let me know what version of alsa-driver you are using.

1 Jul 2004

I've got a version up the I think fixes the Audigy problem. Since I'm not able to test it myself I don't know for sure. But I've had a couple of people say that it works, so I guess it does.

With the Audigy code comes 7.1 speaker support. You'll need a newish ALSA from CVS. Since I don't have the hardware to test this I'm going to need someone to check that it works correctly.

The other big thing in this release is a code speedup. I've removed the float to int conversion from the inner loop that copies the audio data into the ring buffer. I'm uses 16.16 fixed point instead.

30 Jun 2004

There is an article about this in LinuxGames.

I've just found out that it does not work for Audigy cards. This is due to the Audigies having twice the number values in the send mixer controls. You can expect a fix in the next few days.

28 Jun 2004

New version up. A couple of bug fixes. There was a mistake in the matrix multiply function. And it was not buffering 8bit mono data correctly.

12 Jun 2004

I've got it all working. All problems that I know of are fixed. At least with my code. I'm still not happy about being limited to 21 sources.

10 Jun 2004

I found out what the slowdown was; I had left the code where is sets the period and buffer sizes commented out. When you don't specify the period size of number ALSA sets the period size to as small as it can. This had the result of making the interrupts far too frequent.

8 Jun 2004

Finally gotten around to releasing a thread safe version. It seems that messing about with the async handler and semaphores didn't work very well; I was getting lots of buffer underruns. I ended up going with a async thread that updates all playing sources. And then does a timed sleep before updating again.

Testing it I ran into a couple of problems. First, there is the fact the ALSA is using PCM voices for timing which means there are less available for PCM output. For example the Soundblaster Live has 64 PCM voices, which should mean you are able to have 32 stereo PCM streams. But with ALSA at the moment you can only have 21 (64 / 3 = 21).

The other, more important, problem is one of performance. I was getting severe slowdown with UT2004 on the DesertIsle map, yet it runs fine with the software OpenAL. There is nothing about my code that would explain the slowdown. It is most definitely doing less work. So that has kind of put a damper on the whole project for me.

Apart from the performance the only know problem remaining is it is very sloppy about stopping the audio streams. This may be causing clicks and pops when it finishes playing a sound. It is also setting the source state to stopped prematurely.

3 Jun 2004

After coming home from the pub tonight I appear to have managed to get release out the door. I hope I've not made too much of a fool of myself.

2 Jun 2004

I've got it working, sort of. It's still missing some stuff and it is not yet thread safe. In fact it is just not safe; according to what I've read in an ALSA mailing list calling ALSA functions from within ALSA's async callback is not safe. Which is what I'm doing at the moment. Which would explain why UT2004 runs for bit and then crashes when using my library.

However, I have a plan. I'm going to add a couple of mutices to get basic thread safety. It'll have to spawn a thread to handle OpenAL's async functionality. And finally a semaphore to let this thread know that an update is needed. If I stick with the async callback I can simply set a flag and call sem_post(3) from the handler. Which is signal safe most places. This should be better than juggling all those file descriptors.

I'm thinking of putting the code up before doing all that. I want to do some more testing and tweaking before then. I also want to get a couple of bits and pieces finished first but I'll probably leave off doing that WAV file loader until later. But I'm not going to get a chance to do any of that until at least Friday evening now.

1 Jun 2004

Out with the old, in with the new. Well, almost. I've removed what was here because it was all so obsolete. I'm almost ready to put up my first release of a hard aware accelerated OpenAL that should work with any card that uses ALSA's EMU10K1 driver.