Member Avatar for aradicev
aradicev 0 Newbie Poster

Hi,

I have run into an obstacle while trying to restart a direct sound device on windows 7. What I'm doing is clasical stuff:

  1. Create the interface
    DirectSoundCaptureCreate8(CConfig::GetMainSoundDeviceCaptureGUID(), &m_radioRecordObj, NULL);
  2. Create the buffer
    m_radioRecordObj->CreateCaptureBuffer(&m_radioRecordDesc, &pDsb, NULL);
    ...
    pDsb->QueryInterface(IID_IDirectSoundCaptureBuffer8, (LPVOID*) &m_radioRecordBuf);
  3. Start the buffer
    m_radioRecordBuf->Start(DSCBSTART_LOOPING);

after some time I'm stopping and releasing the buffer
m_radioRecordBuf->Stop()
m_radioRecordBuf->Release();

and after that i repeat the former sequence for creating the interface and creating and starting of the buffer.

The scenario is: I start the program on a remote machine and it runs smoothly, even the restarting of the sound interface, up to the point when I dissconnect (not logging out, just dissconect) from the remote machine. After that, the first sond interface restart produces an error (DSERR_NODRIVER) when calling DirectSoundCaptureCreate8.

I have produced this behaviour on a local macnine too by locking the machine (Windows logo key and the + L).

Further more, I have tried to schedule the start of the application after I have dissconected from the machine. And guess what, the applicaton runs ok, but only until I connect to it via remote desktop when it again breaks with DSERR_NODRIVER on the first sound interface restart.

Hope that someone has stumbled over this problem and has a solution to it.

Regards

Andrija

Edited by aradicev
  • 1 Contributor
  • 0 Replies
  • 213 Views

Dani AI

Generated

Note for : DSERR_NODRIVER means DirectSound could not find a usable capture driver or endpoint — the API will return this when the driver/endpoint is removed or not present. (learn.microsoft.com)

Why this typically happens in your scenario: session switches, locking, and RDP connect/disconnect often change which audio endpoints are available (and RDP can redirect or block microphone capture via policy), so a previously valid device GUID can suddenly refer to nothing. Recreating a DirectSound capture object against a missing endpoint will fail (DSERR_NODRIVER is explicitly a possible return). (learn.microsoft.com)

Recommended, robust approach (practical steps):

  • Stop trying to blindly recreate the old DirectSound objects after a session change. Watch for session-change events (WTSRegisterSessionNotification / WM_WTSSESSION_CHANGE) and treat lock/unlock / remote connect/disconnect as points to pause/re-try initialization. (learn.microsoft.com)
  • Use the MMDevice API to enumerate endpoints and register an IMMNotificationClient so the app is told when a device is removed, added, or the default changes; only re-create capture buffers when a usable device is present. (learn.microsoft.com)
  • Prefer using WASAPI / MMDevice for new code: it supports endpoint notifications and stream switching and is the recommended modern path on Vista+ (Windows SDK samples show how to handle capture and stream switching). (learn.microsoft.com)

A compact event-driven pattern (pseudocode):

RegisterWTSNotifications(hwnd);
RegisterIMMNotifications();

on WM_WTSSESSION_CHANGE:
  if (WTS_SESSION_LOCK or WTS_REMOTE_DISCONNECT) suspend init;
  if (WTS_SESSION_UNLOCK or WTS_REMOTE_CONNECT) attempt reinit();

IMMNotificationClient::OnDeviceRemoved(id):
  release current capture

IMMNotificationClient::OnDefaultDeviceChanged(role,id):
  attempt reinit()

attempt reinit():
  enumerate capture endpoints; if found create capture; else schedule retry with backoff

Checklist / cautions: call CoInitialize on the thread that touches MMDevice/DirectSound, release all COM objects before re-creating, prefer enumerating current devices (or passing the default endpoint) instead of using a stale GUID, and implement a retry/backoff instead of tight loops. Also verify RDP audio/capture redirection policies on the host if the app must run under Remote Desktop. (learn.microsoft.com)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.