Home/ Questions/Q 6831435
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T22:44:14+00:00

I am considering doing something that might seem strange to get a reliable time

  • 0

I am considering doing something that might seem strange to get a reliable time clock. I have to push buffers to a WiFi connected audio output device that does not do buffering or audio timestamp arbitration on its own. If I don’t send the buffers at regular periodic intervals that would match reasonably the timing of a hardware sampler device, the playback becomes corrupted and starts to stutter.

I looked at the usual suspects for doing high resolution timing first before considering the “hack” I describe below. QueryPerformanceCounter looked good until I read about buggy hardware implementations in the Harddware Abstraction Layer and the complexities of variable CPU speed stepping ruining the QPC calculations. Also, the Windows multimedia timer is only accurate to 1 millisecond making its use at high sampling rates like 44.1 kHz dubious. That’s why I am considering the following:

CPU clock frequency and thus QueryPerformanceCounter wrong?

As far as I know every Windows PC currently made has at least hardware support for a microphone. What I am considering doing is “piggybacking” on an existing capture device’s clock. I have a DirectShow push source filter that is the true source of the audio to be sent to the WiFi audio output device. I will force the Capture Filter’s sample rate to match the push source filter. Then, I will use a semaphore to lock the push source filter’s FillBuffer() call until the Capture Filter’s FillBuffer() call produces a buffer, thereby riding the Capture Filter’s buffer timing.

Can I count on a user’s PC having at least one Capture Device? Also, any comments about the overall strategy are appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    System Reference Clock is a relaible clock with around millisecond accuracy, and you have it in any PC with or without DirectShow capture devices.

    The problem one might be dealing with is that tghis clock does not exactly match the clock of audio capture or playback device, and a long term sound streamed accumulates an error due to mismatch of the clocks. DirectShow rate matching is something to address the problem.

    On the other hand if you need a good clock with higher accuracy/precision, you can use the one backed by QueryPerformanceCounter but being resync’ed on a regular basis to keep long term accuracy, see class DateTimePrecise.

    Also:

    • 0