Program crashes when no speakers are plugged in

Started by
12 comments, last by NaturalBornCamper 14 years, 2 months ago
Hay! I'm using DirectAudio with my project but the application crashes when there are no speakers/headphones plugged in... What the?? Anybody has ever seen that before and knows how to fix it? Thanks! Marco
Rise And Shine
[size=2] - The G Man
Advertisement
if you're using Visual Studio, run it with debugging and when it decides to die, you can have it break at the scene of the accident.

maybe this will help put you on the right path.
Found the spot where it's doing that already, but can't figure out why, that's why I thought maybe someone already had that problem.
Rise And Shine
[size=2] - The G Man
My guess would be that you're using USB speakers, and when they're not plugged in there's no audio device, so grabbing some interface fails, and you don't check whether it failed, and instead you dereference a null or uninitialized pointer.
This might also happen with non-USB sound devices (3.5mm, optical, etc) if the hardware is able to detect that something is plugged in or not. My onboard sound device does this.
Quote:Original post by Nypyren
This might also happen with non-USB sound devices (3.5mm, optical, etc) if the hardware is able to detect that something is plugged in or not. My onboard sound device does this.
Yeah, mine too. With Vista, they added a feature to disable the sound device if there's no speakers plugged in.
Quote:Original post by NaturalBornCamper2
Found the spot where it's doing that already, but can't figure out why, that's why I thought maybe someone already had that problem.
Well, if maybe you tell us what your code is doing at the point it fails, we can figure it out. As it is, all we can do is guess...
I discovered this unsightly new feature of Vista at work. We make audio hardware here and our config app is in C#. On my dev machine which now has Vista, it all crashes if I don't have speakers plugged in. Stupid!
Quote:Original post by BLiTZWiNG
I discovered this unsightly new feature of Vista at work. We make audio hardware here and our config app is in C#. On my dev machine which now has Vista, it all crashes if I don't have speakers plugged in. Stupid!
I agree - It is stupid that you're not correctly checking for errors in your code and letting it crash [smile]
TEsted a few different configurations guys, and it's not only in Vista, it's the same with Windows7 and XP, but in XP, it only happens when you disable your sound card in the device manager.

So the error happens at that point:

mSoundDevice = DirectSoundCreate8( NULL, &mDirectSound, NULL );
assert( mSoundDevice == DS_OK ); // That would make it crash here
Rise And Shine
[size=2] - The G Man
Quote:Original post by NaturalBornCamper2
TEsted a few different configurations guys, and it's not only in Vista, it's the same with Windows7 and XP, but in XP, it only happens when you disable your sound card in the device manager.

So the error happens at that point:

mSoundDevice = DirectSoundCreate8( NULL, &mDirectSound, NULL );
assert( mSoundDevice == DS_OK ); // That would make it crash here
That won't crash, it'll assert - there's a big difference. It will however crash as soon as you try to use the pointer.
What that code says is: "In debug mode I want to know about problems by breaking to my debugger. In release mode, just ignore the return value". You need to check the return value and correctly act on it, like so:
// I assume mSoundDevice was a member variable - why? It's just the success// or error code for DirectSoundCreate8, you don't need to keep itHRESULT hResult = DirectSoundCreate8( NULL, &mDirectSound, NULL );if(FAILED(hResult)){   // Some error occured   assert(false); // Break to debugger if it's running   // Log the error   // Bail out, and signal that this failed - show the error and exit the app,   // or continue without sound.   return false;}
You really need to check for errors at any point where a function returns information you rely on (E.g. fills out a DSCAPS struct or returns a pointer such as in this case), and gracefully handle the case where it fails (By exiting the app, or by having some work around). Failing to do that will result in your end users getting a lovely "This program has encountered a problem and will be closed" message box from Windows, which doesn't look good for anyone.

This topic is closed to new replies.

Advertisement