C++/VB - DirectSound default device changes

Asked By dmorri

25-Nov-08 08:13 PM

I'm using DirectSound for capture and playback in an application, and I
always open the default capture and playback devices by passing 0 to
DirectSoundCreateFullDuplex.  This works fine, but I find that if I change
the default devices (through the Windows control panel) while my app is
running and re-create my DirectSound handle, the device I'm playing through
_doesn't_ change.  It's maintaining some state somewhere about what the
default device was when I started my app.  Does anyone know how to over-ride
this, and open the _true_ current default devices?

This seems to happen whether I pass 0, GUID_NULL, or
DSDEVID_DefaultPlayback/DSDEVID_DefaultCapture as my requested device handles.

Thanks...

-Dan

26-Nov-08 09:41 AM

Hi Dan,

Your application should be seeing the changes with the exception of handles
that are already open.  At least that is the way that I remember it and is
the way that waveIn/waveOut work.  The application's top level window
receives a device change notify message which is automatically processed,
are you perhaps running in a console?

As a test can you inject the code from my DirectSoundEnumerator sample?  It
would be interesting to see the enumeration and the associated wave device
Id's with each device both before and after.

--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]

26-Nov-08 11:45 AM

Interesting... I'm not running in a pure console application, but to be
honest the message-handling loop in this app is somewhat complex and I'm not
sure if I could be doing anything that causes messages to get eaten
inappropriately.  It's a WPF app with a large managed layer on top of
unmanaged DirectSound... I will take a look at whether I'm preventing
messages from getting to DSound.

Any idea what "automatically processed" means?  Does DSound explicitly
inject a custom message handler into the app?

Thanks!

-Dan

26-Nov-08 04:40 PM

Actually I think the message is purely informational.  The application can
choose to process it if it wished to close and reopen it's audio device for
example.  It shouldn't matter whether you receive messages or not AFAICT.

However something appears to be funky with DirectSound.  As a test I ran my
DirectSoundEnumerator app, which allows you to re-enumerate at will with
the click of a button.  The DirectSound enumeration information is getting
cached and is the same for each iteration.  On the other hand, inserting a
call to waveOutGetDevCaps() returned the correct (up to date) results for
each iteration.

I will check whether unloading the DSound.DLL changes this behavior.  But
that's a little more difficult as you can't bind at link time.

--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]

26-Nov-08 06:48 PM

Unloading the DSound.dll works, however there seems to be a bug in the
DSound.dll reference counting as if you call LoadLibrary() (and only
LoadLibrary) you must call FreeLibrary() twice to get the DLL to actually
unload.  When I do this I get the correct enumeration on the reload.

--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]