My Windows OpenAL DirectSound3D sound woes

Ok, time for a new posting about windows sound woes... here we go.

I've been pounding on the sound issues I've noticed with Torque's implementation of openAL, since I would like to get it as solid as I can before I start showing off too much of my game.

Here's what I've found so far:

1) Torque's openal.dll (from HEAD) was working fine as a software sound renderer with my original on-board sound solution, but I was not very happy with the software rendering features (for one, doppler in the software renderer seems to be muffed. The equations don't use alDopplerFactor nor alDopplerVelocity properly, and the system seems like it has other issues with software doppler rendering as well).

2) One problem I ran into was with my on-board sound: I am running XP-Pro on an MSI motherboard (K7N2-DeltaL). This motherboard had an option with and without an included 5.1 hardware sound chip; mine was the motherboard option WITHOUT the on-board sound processing chip, so I was stuck without a method of testing hardware sound rendering. Problem: If I try to install openAL with the original motherboard sound drivers, it tells me to upgrade my sound drivers before I can install OpenAL. The Unified drivers that NVidia makes for the N2 audio series motherboards enumerates my motherboard as supporting EAX, but uhmmm, it doesn't have the hardware for it.

3) I purhcased a Soundblaster Live! 5.1 card for $30 last night to start testing out hardware rendering, but I ran into two new problems right away.

4) First, with SoundBlaster Live! after I installed the latest openAL runtime (with router & wrapper) I get crashes with the Torque version of openAL.dll

5) Second, when I removed the torque openal.dll file from the working directory, the newer openAL system does not properly enumerate the new soundcard, so it tries to default openAL to use DirectSound3D as its basis for rendering: For this, I've found a fix that works by altering a line in the openAL library code: in openal/win/router/alc.c at line 1686, there is a built-in fix for Creative Audigy series hardware, but the same fix should be applied to Soundblaster Live! cards: for this, I simply altered the built-in check:

if (strstr(mixerDevice, "Audigy") != NULL
// jgr - added for SoundBlaster Live support
|| strstr(mixerDevice, "Live") != NULL) {

Now, when I use my compiled version of the openAL router, my system is properly enumerating the soundblaster Live card and using the hardware to render sound... woohoo! no problems apparent with this yet when I use the latest Creative sound drivers for Live!

Finally, I am just now starting to go back and try to debug why software rendering is still crashing things. I have so far found that if I tell openAL to use "DirectSound3D" or "DirectSound" as its renderer, I can get into torque, but I hear no sound in it. If I tell openAL to use the "MMSYSTEM" driver for debugging purposes, thats when I see the crashes. Since this is running through software, I ought to be able to use debug to find why this is happening.

When I try software rendering by opening the "MMSYSTEM" device, I am seeing Torque initialize OpenAL properly, but when I try to play a sound, then I get the crash. So far, it appears that Torque is trying to call alGetBufferi(0,AL_CHANNELS,&value) for an uninitialized Buffer0 when the crash occurs.

I'll post another thread in this forum if I find any further solutions. I certainly want Torque to be able to properly enumerate hardware and fall back to a viable software renderer when hardware is not present.