richardjmoss's picture

Resetting OpenAL buffers


I've been having a couple of peculiar issues with OpenAL which hopefully someone has come across before.

1. Firstly, every so often my application randomly crashes when creating sound buffers. For example, when the application starts, it loads 32 WAV files into buffers and channels. When the application shuts down, it releases these channels and buffers. But every so often, the application will start up and then completely hang when creating processing a WAV file. There's no pattern, it happens with random files. And not only does it freeze, it's completely unkillable - I have to restart the system to get rid of the app. taskkill, procexp, taskman etc all fail to kill the process, which itself is running at 100% on one core.

The code that loads the files is derived from the Playback OpenAL sample shipped with OpenTK, the only "extra" bit I've added so far is looping support.

2. The second issue is a cleanup issue. If the app crashes while debugging, or if I terminate the debugging session, the OpenAL buffers don't seem to be automatically cleared in the same way that OpenGL texture buffers do. Therefore if I run the application again, and request to create new buffers and channels, they don't seem to be loaded correctly - instead the sounds from the previous run are present. Again, I haven't figured out a way to reset these other than by rebooting the system.

For example, I had a bubbling sound that was loaded into source 1, buffer 1, and a ding in source 2, buffer 2. I terminate the debugging session and restarted, this time reversing the load order. So I should have had ding in 1/1, and bubbling in 2/2, but instead I had bubbling in 1/1 and corrupt static in 2/2. This persisted until rebooting, at which point the new order was loaded correctly. If the application shuts down correctly this problem doesn't occur, it's only when terminated without perform delete actions. (Which is understandable, but not being able to flush them out as GenSource and GenBuffer are returning the same numbers each time so it seems to think they are free is not so understandable)

So, a couple of questions:

1. Is my approach of loading sounds at application start and them releasing them at application end the best approach, or should I create them each time the sound is played. I'm assuming not, but I'm perplexed by these freezes. I've never encountered the inability to kill a process before!

2. Is there a way of clearing out the buffers in order to reset them without requiring a machine reset. I'm assuming the data is being stored on the sound card, definitely somewhere independent as restarting the app, devenv, etc don't help.

3. In the same way I load sources/buffers once for the lifetime of the app, I also create on AudioContext for the life of the app - if this isn't what you should be doing, then how do you handle playing sounds (especially looping ones?)

I've only been playing with OpenAL since this morning so I daresay I'm missing something somewhere, any advice anyone can offer would be appreciated.

Richard Moss

Edit: I thought I should probably point out the hardware - Creative SoundBlaster X-Fi Xtreme Gamer Fatal1ty Pro, driver version 2.18.15. There doesn't seem to be a newer driver available.

Edit 2: Just got the freeze again and its on the AL.BufferData statement if that's of any help.

Edit 3: This is nuts. Rebooted after the freeze and fired up iBomber Defense. Which was unplayable due to half the sounds being static. Fired up my game, and found that now *it* was playing iBomber sounds. Have I managed to fry my soundcard?


Comment viewing options

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

Quick update: After spending the last week doing the development on my laptop without a single freeze or misplaced sound, I was back on my desktop tonight, and within 5 mins had my first freeze. I tried disabling my X-Fi sound card and went with onboard sound, and I've been merrily working away without a problem since.

One strange thing I have noticed, is when using the onboard sound of either my desktop of the laptop, the source/buffer ID's look something like this:

source 168442816, buffer 168442864
source 168444216, buffer 168444264

Each run, those numbers are completely different.

However, when running under the X-Fi, the numbers are like this:

source 1, buffer 1
source 2, buffer 2

And the numbers never change, even between successive runs of the app. No idea if this is pertinent, or just how the drivers work.

Regardless, it seems the issue is with the X-Fi card or its drivers, rather than my code. Hopefully anyway.

It's still puzzling.