IAudioClient::Initialize succeeds but sometimes takes ~15 seconds RRS feed

  • Question

  • In most instances, my calls to IAudioClient::Initialize() return immediately, but I have one customer on Win7 SP1 that occasionally gets a 15-second delay, although the API call does complete successfully. As this is a VOIP application, the VOIP caller has long since hung up by the time IAudioClient::Initialize() call returns.

    I only have vague descriptions of the context of this problem. It may be associated with the first call after a new user logs in, or after the PC comes out of sleep. In the most recent example, I see log entries for the hour prior to the incident, so the user had not just logged in or just brought the PC out of sleep, but it may still be the first call since booting, logging in or waking from sleep. We've tried having them disable sleep and other power-related options with no luck.

    My call to Initialize() looks like:

        hr = m_pAudioClient->Initialize(AUDCLNT_SHAREMODE_SHARED,
                                        reinterpret_cast<const WAVEFORMATEX*>(pWaveFormat),

    Again, when we have the problem, this call succeeds; it just takes 15 seconds when it would normally only take a few ms. The audio device, in this case, is a GN 8110 USB headset. We have lots of customers using this same headset and driver version with no problems.

    Any ideas about what might be causing this delay are appreciated.

    Tuesday, April 16, 2013 5:38 PM

All replies

  • Could be an issue with the USB controller.

    Matthew van Eerde

    Tuesday, April 16, 2013 7:10 PM
  • I have exactly the same issue on my VOIP application, did you have a fix or explanation?
    Wednesday, December 4, 2013 3:54 PM
  • Is this also with a USB audio device? Or some other audio device?

    Matthew van Eerde

    Thursday, December 5, 2013 5:12 PM
  • Is this also with a USB audio device? Or some other audio device?
    I still haven't found a solution to this. I have another case now where it's taking 30 seconds to return and the device is a "GN 2000 MS USB", USB headset. Any ideas? Btw, once it succeeds, I can release the IAudioClient and create another and it succeeds immediately until the computer is reboot, then the first Initialize takes 30 seconds.
    Tuesday, April 1, 2014 3:13 AM
  • Go into Device Manager and View | Devices by connection.

    Find the USB controller - this is the parent or grandparent of the problem USB audio device.

    Post the name of the controller as it is displayed in Device Manager.

    Also, right-click the controller | Properties | Details | set Property to Hardware Ids

    Copy and paste the top line of the Value field. For example, mine looks like this:


    (I'm not hitting the problem, though.)

    Matthew van Eerde

    Tuesday, April 1, 2014 9:48 AM
  • We have the same problem in our system: After booting the PC, the very first call to IAudioClient::Initialize() *sometimes* blocks for 25..30 seconds. After waiting that time, IAudioClient::Initialize() returns with hr=0 and the audio is running. After that, all further calls to IAudioClient::Initialize() are returning immediately without any issues.

    Affected Audiodevice: "Realtek High Definition Audio", Playbackdevice

    Realtek Driver Version:

    Realtek Hardware Ids: HDAUDIO\FUNC_01&VEN_10EC&DEV_0888&SUBSYS_10EC0888&REV_1002

    Operating System: Windows 7 Ultimate SP1 (32-bit)

    Please let me know, if there are some workarounds or bugfixes available, Thanks.

    Tuesday, October 6, 2015 9:18 AM
  • Have you found any solution to this? The same problem occurs occasionally on my testing machine...
    Monday, June 26, 2017 2:55 PM
  • That's an old thread but it looks like the problem is still there. I am also having 30-second hangings on my test machine when calling IAudioClient::Initialize. Any plans to address this?
    Tuesday, November 12, 2019 7:41 PM
  • Since you have a repro, please file a problem report, including "recreate my problem" logs of the problem in action.

    Once filed, share a link to the problem report here.

    Matthew van Eerde

    Tuesday, November 12, 2019 8:42 PM