locked
Using IAudioClock::GetPosition instead of waveInGetPosition RRS feed

  • Question

  • I'm supporting a legacy application that uses waveXxxx audio. The doco for waveInGetPosition states the function is not supported from Vista and that IAudioClock::GetPosition should be used. Apart from that I have a need to get a byte position in the stream beyond the DWORD that waveInGetPosition returns.

    However I cannot find any way to get the IAudioClock, via IAudioClient from the waveInOpen handle. Is there a way to do this? That is, getting a hold of the IAudioClient that waveIn... uses underneath?

    Thanks!.

    Sunday, June 14, 2020 8:14 AM

All replies

  • IAudioClock

    is used in WASAPI, like for example in

    Capturing a Stream

    (IAudioClock* pAudioClock;

    pAudioClient->GetService(__uuidof(IAudioClock), (void**)&pAudioClock);

    // etc...

    )

    Sunday, June 14, 2020 9:55 AM
  • IAudioClock

    is used in WASAPI, like for example in

    Capturing a Stream

    (IAudioClock* pAudioClock;

    pAudioClient->GetService(__uuidof(IAudioClock), (void**)&pAudioClock);

    // etc...

    )

    Thanks, but the question is how to use IAudioClock in relation to a HMMIO opened usine waveInOpen? The waveInGetPosition doco implies that you can but I cannot see any way to do this.

    Sunday, June 14, 2020 10:54 PM
  • No, what the document is saying is that the ENTIRE MMIO subsystem is no longer supported.  They aren't saying "use IAudioClock with your waveIn endpoint".  They are saying "throw out all of your waveIn code and rewrite it to use the Audio Engine instead."

    Mostly, they are wrong.  waveIn and waveOut work just fine and will continue to work just fine for the foreseeable future.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Monday, June 15, 2020 12:49 AM
  • No, what the document is saying is that the ENTIRE MMIO subsystem is no longer supported.  They aren't saying "use IAudioClock with your waveIn endpoint".  They are saying "throw out all of your waveIn code and rewrite it to use the Audio Engine instead."

    Mostly, they are wrong.  waveIn and waveOut work just fine and will continue to work just fine for the foreseeable future.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Thanks Tim, I hear what you are saying there. I remember the kerfuffle in 2006 when the audio system was rewritten and the mixer meter values disappeared. I did think that as the proviso is not stated in any of the other waveXxxx functions, that this was particular to this function alone, and that there would be a way to get to the IAudioClient that the waveInxxx functions are using underneath. The waveInGetPosition is still functioning as expected - I just was interested in getting a 64 bit position. Cheers/
    Monday, June 15, 2020 2:03 AM
  • I don't know how invested your application is, but WASAPI is really quite flexible and not that much harder to use than waveIn.

    I'm not convinced winmm is actually using WASAPI under the hood.  It's possible, I suppose, but I suspect that all three major audio systems (waveIn/waveOut, DirectSound, WASAPI) are actually using some lower-level scheme to communicate with the Audio Engine.


    Tim Roberts | Driver MVP Emeritus | Providenza & Boekelheide, Inc.

    Monday, June 15, 2020 9:57 PM
  • WinMM APIs use Core Audio APIs (see the MS graph below)

    but there is no direct relation, they communicate by RPC (AudioClientRpc)

    Tuesday, June 16, 2020 8:10 AM