siberian
30-04-2008 15:12:35
It appears there is a problem with the XRam code in:
SoundManager::getSingleton().eaxSetBufferMode(...)
The program will crash when ever you load a sound. The line it crashes on is:
if(mSetXRamMode(numBuffers, buffers, bufferMode) == AL_FALSE) return AL_FALSE;
from the aforementioned eaxSetBufferMode(...) function
I tried debugging it myself and found that the 'BufferRef *buffers' parsed into eaxSetBufferMode() gets corrupted on passing. Also im not sure about the 'Size numBuffers' parsed variable but in one example the passed int was 4096 but by the time it got into the function and cast to Size 'numBuffers' became 2. So assuming Visual Studio is not being stupid then i think there are some issues here.
Anyway heres my log
*-*-* Creating OpenAL
23:59:54: OpenAL Version: 1.1
23:59:54: Available Devices
23:59:54: -----------------
23:59:55: * Auzen X-Fi Audio [EC00]
23:59:55: * Generic Software
23:59:55: Choosing: Auzen X-Fi Audio [EC00]
23:59:55: Supported Formats
23:59:55: -----------------
23:59:55: EAX 5.0 Detected
23:59:55: EFX Extension Found
23:59:55: X-RAM Detected
23:59:55: X-RAM: 285344770 (285344769 free)
23:59:55: Creating OgreAL Thread
23:59:55: Creating resource group Sound
23:59:55: Added resource location 'Data/Sounds/Music' of type 'FileSystem' to resource group 'Sound'
23:59:55: Initialising resource group Sound
23:59:55: Parsing scripts for resource group Sound
23:59:55: Finished parsing scripts for resource group Sound
23:59:55: === Setting X-RAM Buffer Mode
23:59:55: === Allocating 0 bytes of X-RAM
and its at this point that it crashes. This is only a problem for cards with XRam detected as it works perfectly for my onboard. also if i just comment out the call to 'eaxSetBufferMode' from 'Sound::generateBuffers()' then everything works fine again.
Has anyone else with an XRam capable soundcard had this problem. Has anyone else actually tested it! And if it cant be easily fixed then perhaps someone could add a user configurable option so that it doesn't automatically try and load into XRam just because its there and instead lets there user decide if it should do that. I could write that up myself reasonably quick but i figured CaseyB would probably want control over what happens (and also hes the one controlling the svn).
Anyway if anyone else has a XRam card let me know as im curious to see if its just the Auzen variants or all X-Fi cards that do this.
SoundManager::getSingleton().eaxSetBufferMode(...)
The program will crash when ever you load a sound. The line it crashes on is:
if(mSetXRamMode(numBuffers, buffers, bufferMode) == AL_FALSE) return AL_FALSE;
from the aforementioned eaxSetBufferMode(...) function
I tried debugging it myself and found that the 'BufferRef *buffers' parsed into eaxSetBufferMode() gets corrupted on passing. Also im not sure about the 'Size numBuffers' parsed variable but in one example the passed int was 4096 but by the time it got into the function and cast to Size 'numBuffers' became 2. So assuming Visual Studio is not being stupid then i think there are some issues here.
Anyway heres my log
*-*-* Creating OpenAL
23:59:54: OpenAL Version: 1.1
23:59:54: Available Devices
23:59:54: -----------------
23:59:55: * Auzen X-Fi Audio [EC00]
23:59:55: * Generic Software
23:59:55: Choosing: Auzen X-Fi Audio [EC00]
23:59:55: Supported Formats
23:59:55: -----------------
23:59:55: EAX 5.0 Detected
23:59:55: EFX Extension Found
23:59:55: X-RAM Detected
23:59:55: X-RAM: 285344770 (285344769 free)
23:59:55: Creating OgreAL Thread
23:59:55: Creating resource group Sound
23:59:55: Added resource location 'Data/Sounds/Music' of type 'FileSystem' to resource group 'Sound'
23:59:55: Initialising resource group Sound
23:59:55: Parsing scripts for resource group Sound
23:59:55: Finished parsing scripts for resource group Sound
23:59:55: === Setting X-RAM Buffer Mode
23:59:55: === Allocating 0 bytes of X-RAM
and its at this point that it crashes. This is only a problem for cards with XRam detected as it works perfectly for my onboard. also if i just comment out the call to 'eaxSetBufferMode' from 'Sound::generateBuffers()' then everything works fine again.
Has anyone else with an XRam capable soundcard had this problem. Has anyone else actually tested it! And if it cant be easily fixed then perhaps someone could add a user configurable option so that it doesn't automatically try and load into XRam just because its there and instead lets there user decide if it should do that. I could write that up myself reasonably quick but i figured CaseyB would probably want control over what happens (and also hes the one controlling the svn).
Anyway if anyone else has a XRam card let me know as im curious to see if its just the Auzen variants or all X-Fi cards that do this.