We're getting a relatively rare crash in XAudio2_1.dll with the XACT3 release runtime, and a trace message with the debug runtime. We're not completely sure whether the two are related. We haven't found a pattern how to reproduce the problem yet.
 
Here's the trace message from the debug output when XACT3 is initialized with XACT_FLAG_API_DEBUG_MODE:

"e:\dxsdk\jun08\audio\wma\codecv10\wmaudio\decoder\msaudiodec.cpp(2291) : *** TRACE *** code = 0x6!"

And here's the call stack when the crash happens if XACT3 is setup in release mode:

> XAudio2_1.dll!CX2SourceVoiceWMA::UpdateLeapVoiceQueue()  + 0x7d5 Bytes 
  XAudio2_1.dll!CX2SourceVoiceWMA::OnVoiceProcessingPassStart()  + 0x34 Bytes 
  XAudio2_1.dll!CSWVoice::Process()  + 0x1e4 Bytes 
  XAudio2_1.dll!CGraphManager::ProcessGraph()  + 0xc3 Bytes 
  XAudio2_1.dll!CGraphManager::ThreadProc()  + 0x1b8 Bytes 
  XAudio2_1.dll!CThreadBase::StaticThreadProc()  + 0x38 Bytes 
  kernel32.dll!_BaseThreadStart@8()  + 0x37 Bytes

Anybody know what's going on there? The debug output message isn't very helpful unfortunately, also the problem doesn't seem to be easily reproducible, simply playing back all of our audio content in a test program hasn't triggered the bug so far.

Thanks & regards,
-Floh

 

We haven’t seen anything like this before.  The crash only occurs on the retail DLL while playing a cue with an xWMA sound?  The stack occurs past XAudio2’s internal data validation, and the debug message even deeper still at a point where it is difficult to ascertain the cause without more context.  Is there any correlation between the failure and the specific xWMA format (channels, sample rate, bitrate)? 

Hello Duncan, thanks a lot for your reply.

I would like to send you a minidump of the crash, it would be great if you could contact me directly at "floh _at_ radonlabs.de".  It's a null-pointer read access deep in CX2SourceVoiceWMA::UpdateLeapVoiceQueue().

We're see the bug since we switched our project to XACT3 about one week ago, it doesn't trigger very often but unfortunately completely random (I get about 1 of those every 2 days with about 20 testers hammering on the game, and I wasn't able to reproduce them).We're not talking directly to XAudio, but run everything through XACT3. Since the bug happens in another thread I'm unable to track the problem back to a specific audio cue. We're having quite a lot of audio content (about 6000 source samples), where streaming speech and music is in xWMA format if possible (it looks like relatively small source wavs (under ca. 200kByte?) won't convert to xWMA?) everything else is in ADPCM. Source files are all in 16bit, 44100 Hz, mono or stereo. Until yesterday we had both ADPCM and xWMA data mixed in the same streaming wave banks, I split this up into separate wave banks now, but that's just a shot in the blue sky. It doesn't seem as simple as a broken xWMA stream though, I wrote  a little test program which plays all existing cues one after another and let that program run over night without a crash or trace message.

Regards, -Floh.

 

Some more info I just excavated from the crash dump: when the crash happens in an XAudio CGraphManager thread, the main thread is somewhere deep in XACT::CCue::Destroy, waiting in CGraphManager::WaitForThread(). Could this be a multithreading issue where the graph manager thread tries to access data which has already been free'd by the main thread?

Here's the call stack of the main thread:

     XAudio2_1.dll!_XLFQueueAdd@8()  + 0xa7 Bytes   
     XAudio2_1.dll!CGraphManager::WaitForThread()  + 0x2d Bytes   
     XAudio2_1.dll!CLeapSystem::WaitForGraph()  + 0x10 Bytes   
     XAudio2_1.dll!CX2SourceVoice::Destroy()  + 0x82 Bytes   
     XAudio2_1.dll!CX2SourceVoiceWMA::~CX2SourceVoiceWMA()  + 0x33 Bytes   
     XAudio2_1.dll!CX2SourceVoiceWMA::`scalar deleting destructor'()  + 0x11 Bytes   
     XAudio2_1.dll!CMemoryHelper::Delete<CX2Voice>()  + 0x32 Bytes   
     XAudio2_1.dll!CX2Voice::InternalDestroyVoice()  + 0x2c Bytes   
     XAudio2_1.dll!CX2Voice::DestroyVoice()  + 0x4c Bytes   
     XAudio2_1.dll!CX2SourceVoice::DestroyVoice()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CXAudio2SourceVoice::~CXAudio2SourceVoice()  + 0x2f Bytes   
     xactengine3_1.dll!XACT::CXAudio2SourceVoice::`scalar deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CXAudio2Renderer::DestroyVoice()  + 0x6f Bytes   
     xactengine3_1.dll!XACT::CWave::Cleanup()  + 0xc3 Bytes   
     xactengine3_1.dll!XACT::CStreamingWave::~CStreamingWave()  + 0x3a Bytes   
     xactengine3_1.dll!XACT::CStreamingWave::`scalar deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CEventPlayWave::~CEventPlayWave()  + 0x39 Bytes   
     xactengine3_1.dll!XACT::CEventPlayWave::`scalar deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CClip::~CClip()  + 0x88 Bytes   
     xactengine3_1.dll!XACT::CClip::`vector deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CTrack::~CTrack()  + 0x6a Bytes   
     xactengine3_1.dll!XACT::CTrack::`scalar deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CSound::~CSound()  + 0xad Bytes   
     xactengine3_1.dll!XACT::CComplexSound::~CComplexSound()  + 0x24 Bytes   
     xactengine3_1.dll!XACT::CComplexSound::`vector deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CSound::RegistryHostShutdown()  + 0x4a Bytes   
     xactengine3_1.dll!XACT::CCue::~CCue()  + 0xf1 Bytes   
     xactengine3_1.dll!XACT::CComplexCue::~CComplexCue()  + 0x42 Bytes   
     xactengine3_1.dll!XACT::CInteractiveCue::~CInteractiveCue()  + 0x12d Bytes   
     xactengine3_1.dll!XACT::CInteractiveCue::`scalar deleting destructor'()  + 0x11 Bytes   
     xactengine3_1.dll!XACT::CCue::Destroy()  + 0x4f Bytes   

...and the call stack of the CGraphManager thread where the crash is actually happening (which is a read access from address 0):

    XAudio2_1.dll!CX2SourceVoiceWMA::UpdateLeapVoiceQueue()  + 0x905 Bytes   
     XAudio2_1.dll!CX2SourceVoiceWMA::OnVoiceProcessingPassStart()  + 0x34 Bytes   
     XAudio2_1.dll!CSWVoice::Process()  + 0x1e4 Bytes   
     XAudio2_1.dll!CGraphManager::ProcessGraph()  + 0xc3 Bytes   
     XAudio2_1.dll!CGraphManager::ThreadProc()  + 0x1b8 Bytes   
     XAudio2_1.dll!CThreadBase::StaticThreadProc()  + 0x38 Bytes   

Could this be related to the following known issue:

Don't Flush Source Buffers Immediately Before Destroying a Voice

In the March 2008 and later SDKs, titles should not call IXAudio2SourceVoice::FlushSourceBuffers immediately before calling IXAudio2SourceVoice::DestroyVoice. Titles that do call FlushSourceBuffers immediately before DestroyVoice may cause the title to crash. Titles that must flush source buffers before destroying the voice should insert a short pause between flushing the buffers and destroying the voice. For example, the title might have code similar to the following:
pSourceVoice->FlushSourceBuffer();
Sleep( 2 );
pSourceVoice->DestroyVoice();
In a future release of the SDK, titles will not need to insert the short pause.

We don't call XAudio directly but do anything through XACT3. In this case we do a

 xactCue->Stop(0) followed by xactCue->Destroy()

 Should we do this instead:

 xactCue->Stop(XACT_FLAG_CUE_STOP_IMMEDIATE); Sleep(2); xactCue->Destroy();

 I'll just try that ;)

-Floh.

 

Thanks for the wonderfully detailed information.  I’ll take a look at that minidump offline and post results back to the board. 

We have investigated this crash and believe we have a fix.  The fix has been integrated into the forthcoming August XDK/SDK release.  An internal XAudio2 variable was being incorrectly modified during voice destruction.  The problem only manifests sporadically as it is timing-dependent.  The problem only affects playing source voices; stopping a voice and inserting a short pause before destroying it is a safe workaround.  One may need to increase pause up to 10msec to ensure XACT/XAudio2 stops the voice before destroying it as the realtime audio thread which processes the call runs at a periodicity of 10msec on the PC (the periodicity is 5.333msec on xbox).