locked
WASAPI – Latency control RRS feed

  • Question

  • Does WASAPI provide feedback about the applied buffer size and /or the number of buffers involved in the signal streaming between AD /DA converter and the sound streaming?

    I need the indication of the real latency between analogue output and input.
    I assumed that this parameter could be determined by GetDevicePeriod.
        hr = pAudioInClient->GetDevicePeriod(NULL, &MinDuration);
    With the returned MinDuration  I should achieve a latency of 10 ms. However the real latency varies between 40 and 50 ms (=10 ms difference).
    Now I increased Minduration with factor 5 (50ms)
        hr = pAudioInClient->Initialize( xSHAREMODE,
                                       AUDCLNT_STREAMFLAGS_EVENTCALLBACK,
                                       MinDuration*5,
                                       MinDuration*5,
                                       pwfx,
                                       &(sessionIn));
    in order to get a constant latency, but the latency differs now with 50 ms between 110 and 160 ms.

    Is there any parameter accesible within WASAPI which can be used for the latency indication? If the number of involved buffers of the stream would be available, it could be very easy to determine the real latency.
    If there is no solution: Is the Winapi (winmm) suitable to achieve a constant latency, as the buffer handling is under control of the software developer?

    Kind regards
    Theo

    Thursday, August 13, 2015 2:33 PM

Answers

  • I beleave meanwhile I could solve the problem with the aid of the multimedia counter IAudioClock.

    It seems the problem is caused by the undefined starting conditions of both streams (renderer and capture stream).

    We use now the delay between start() capture client and the first capture event for time alignment and it works now with constant latency.

    kind regards

    Theo

     

    Wednesday, September 9, 2015 9:17 AM

All replies

  • I beleave meanwhile I could solve the problem with the aid of the multimedia counter IAudioClock.

    It seems the problem is caused by the undefined starting conditions of both streams (renderer and capture stream).

    We use now the delay between start() capture client and the first capture event for time alignment and it works now with constant latency.

    kind regards

    Theo

     

    Wednesday, September 9, 2015 9:17 AM
  • Hi Theo,

    I came across a very similar issue (maybe even identical)
    I need to enforce constant latency to a WASAPI renderer. (not capture)
    Where the latency itself is not a concern, just it being constant.

    I need it for a small app I am writing that measures user response times to sound stimuli. ("sound to click")

    I couldn't figure out from your answer how you actually got it.

    I would be grateful if you could share a code snippet, or if not possible, elaborate a little more regarding your solution.

    Many thanks!!


    Sunday, August 7, 2016 6:43 PM
  • There are several buffers between the application and the hardware. You cannot control them all.

    The IAudioClock API will tell you what sample is currently coming out of the speaker or entering the microphone. For capture, the IAudioCaptureClient::GetBuffer call also tells you how old the packet is by the time you get it.


    Matthew van Eerde

    Wednesday, August 17, 2016 11:40 AM
  • Hi,

    my workaround operates as follows:

    1. Start streams with a reference signal (e.g. a burst)

    2. Record the streaming at the microphone buffer

    3. Compute the latency between device buffers (loudspeaker, microphone), at the time after burst is processed plus expected maximum latency. I use for this purpose a correlation analysis.

    4. If latency is in the range (1.25...1.45)*2*buffer Time, the overall latency is stable. E.g. a buffer with 20 ms block length must result in a measured latency between 50 and 58 ms. In this case leave the streams running and process your audio files.

    If the latency condition is not fulfilled, stop streaming and repeat 1-3, until the condition is true. Latency jitter around the block length must appear, if the measured latency is too small or too high. As the start of the streaming is influenced by the current computer load, different latencies are achieved.

    I prevent zero streaming with a small noise added to the loudspeaker buffer.

    Kind regards

    Theo

    Wednesday, September 21, 2016 8:32 AM