[wdmaudiodev] Re: AW: external audio driver clocking

From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
Date: Thu, 23 Aug 2018 14:42:31 +0000

DACs have a clock in them. Audio usually is driven from that clock.

Your driver doesn’t have a DAC. You feed something downstream of you. So you
don’t have a clock yourself; you’re just ratelessly copying bits.

But the thing downstream of you has a clock… or at least, there is eventually a
clock.

To avoid drift, you need to let the clock downstream of you drive your answers
to the Windows position query.

If the clock downstream of you runs slow, Windows will feed data to you slow.
If it runs fast, Windows will feed data to you fast. No drift.

If you lie to Windows about how fast you need data, or just make up an answer
using KeQueryPerformanceCounter, Windows will believe you, but you will drift.

________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Johannes Freyberger <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, August 23, 2018 5:38:27 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] AW: external audio driver clocking

Hmm … my ideas about IMiniportWaveCyclicStream::GetPosition() and
IDmaChannel::CopyTo() meanwhile seem to be the wrong direction for me and I’m
thinking if the dual Xeon system could be a problem and this arises a lot of
questions. Is it guaranteed that KeQueryPerformanceCounter() is synced exactly
between the Xeons? Did this sync change in different Windows OS versions? Could
there be a difference in this when using TSC_INVARIANT or HPET as base for
KeQueryPerformanceCounter()? Can I ensure somehow my drivers are running on the
same cores (in the same Xeon) as my application. I know how to assign my
application to certain cores but is this possible for drivers?

Von: Johannes Freyberger <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Gesendet: Donnerstag, 23. August 2018 13:17
An: 'wdmaudiodev@xxxxxxxxxxxxx' <wdmaudiodev@xxxxxxxxxxxxx>
Betreff: Re: external audio driver clocking

OK, thanks.

So now I’m trying to understand the correlation between
IMiniportWaveCyclicStream::GetPosition() which reports my current DAC position
and IDmaChannel::CopyTo() which gives me access to the next bunch of samples
played by an application. Could it be this drifts apart? Do I have to keep
track of the number of samples delivered in IDmaChannel::CopyTo() and match
this value against my current DMA and thus sample position in
IMiniportWaveCyclicStream::GetPosition()?

Could such an “drift to both directions simultaneously effect” be related to
the hardware or the OS? (So far we’ve seen this drifting effect only on a HP
Dual Xeon Workstation running Windows Server 2012)

Von: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 22. August 2018 20:05
An: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Betreff: [wdmaudiodev] Re: AW: Re: AW: Re: AW: Re: external audio driver
clocking

Yes, that’s correct.

________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Johannes Freyberger
<jfreyberger@xxxxxxxxxxxxxxxxxxxx<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, August 22, 2018 11:04:08 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] AW: Re: AW: Re: AW: Re: external audio driver clocking

Does that mean, the micro-SRC in Windows audio engine will never do anything
except an application explicitly calls IAudioClockAdjustment? It will never
become active by itself? If it’s like this then I misinterpreted your previous
answers - sorry. And I also didn’t want to bark at anything – I thought it was
a normal question.

Von: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 22. August 2018 19:47
An: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Betreff: [wdmaudiodev] Re: AW: Re: AW: Re: external audio driver clocking

The micro-SRC almost always does nothing at all.

If an application wants to connect two different realtime clocks (e.g., an ADC
and a DAC running on hardware clocks) it can either:

  *   Live with the drift
  *   Insert its own micro-SRC
  *   Use Windows’ micro-SRC by calling the IAudioClockAdjustment API

The application would, in the second and third cases, monitor the long-term
real clock rate (slightly different than the nominal clock rate) relative to
some application clock (perhaps QueryPerformanceConter), and then adjust some
or all of the streams to correct the drift.

________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Johannes Freyberger
<jfreyberger@xxxxxxxxxxxxxxxxxxxx<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, August 22, 2018 10:39:50 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] AW: Re: AW: Re: external audio driver clocking

Yes, it’s a drift and it has been worse as long as I was using
KeQueryPerformanceCounter() only without the PTP correction factor.

What makes me think it could be the SRC in Windows audio engine:
- it’s not an identical drift for different instances while my code and the PTP
correction factor is exactly the same for all instances
- so far I’ve seen this effect only on a machine which uses WASAPI non
exclusive and also has recording active while playing

How is the SRC factor computed in Windows audio engine and is it dynamically
adjusted?

Von: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 22. August 2018 19:17
An: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Betreff: [wdmaudiodev] Re: AW: Re: external audio driver clocking

  *   Could this very slow increase/decrease of the jitter buffer be related to
the SRC in Windows audio engine?

No, you’re barking up the wrong tree.

  *   very slow increase/decrease of the jitter buffer

This is “drift”. Your driver is using the wrong clock. You’re using
KeQueryPerformanceCounter, when you should be using whatever is driving the
reads from the jitter buffer.

What’s on the other end of the network stream? Does the network stream feed a
single client or multiple clients?

________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Johannes Freyberger
<jfreyberger@xxxxxxxxxxxxxxxxxxxx<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, August 22, 2018 10:09:03 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] AW: Re: external audio driver clocking

It writes the audio data to the jitter buffer and from there it’s read and sent
to the stream. No SRC etc. is in there, it’s just a buffer with a write and
read pointer.

Could this very slow increase/decrease of the jitter buffer be related to the
SRC in Windows audio engine?

Von: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 22. August 2018 19:03
An: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Betreff: [wdmaudiodev] Re: external audio driver clocking

You said your driver hands data to the application. What does the application
do with it?

________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Johannes Freyberger
<jfreyberger@xxxxxxxxxxxxxxxxxxxx<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, August 22, 2018 9:53:44 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] external audio driver clocking

OK, let’s forget about the bit transparency – I already changed the topic. My
driver is implementing IMiniportWaveCyclicStream and inside GetPosition() I’m
using KeQueryPerformanceCounter() and my “PTP clock factor” to compute the
number of desired samples. All driver instances use the same factor which is
updated every 10 seconds to adjust to drifts due to temperature etc.. The audio
data is then transferred to my application from where I send the stream. Here I
also have my adjustable jitter buffer. In this situation it’s 8000 samples
which is about 160 millisecs at 48 kHz. I think this should be fairly enough
and on my PC the jitter buffer always is about the same for many many hours. On
a customers PC I can see the jitter buffer growing and shrinking very slowly at
the same time for different instances of my driver. This results in buffer
underruns and overruns after several hours and every instance (up to 8) seems
to behave a little different. Some are rather stable. He’s using WASAPI in non
exclusive mode so my guess is this could be due to the SRC in Windows audio
engine as the customer also runs a recording from this device simultaneously.
Could this be true? As his application also offers WASAPI in exclusive mode I
asked him to do some tests in this mode. Hopefully I will receive some logfiles
the next days.

Von: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 22. August 2018 18:24
An: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Betreff: [wdmaudiodev] Re: bit transparency from app to WDM audio driver
depending from API?

Windows audio uses the audio driver’s clock. Usually this is the DAC or ADC,
but your DAC is on the other end of a network. That’s fine, you’ll still need
to use that as the master, and you’ll need to figure out how to rough that
clock into the DDIs Windows uses to talk to you. If you screw it up, though,
there’s nothing the application (or Windows) can do to avoid glitching. You’ll
also have to decide how much of a jitter buffer to keep around to avoid
variable network latency from screwing things up, while at the same time
avoiding introducing too much latency.

This is a totally independent concern from bit transparency, though. I would
suggest starting separate threads for each of your concerns.

From: Johannes Freyberger<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, August 22, 2018 6:20 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Re: bit transparency from app to WDM audio driver
depending from API?

My driver doesn’t run at the internal clock, but at an external PTP master as
I’m going to send the audio data to a RTP network stream. Although PTP is quite
close it’s not the same but something like a factor of 1.00002 compared to the
internal clock (taken from performance counter). Now on some systems this runs
correct for hours and days without over- or underruns, but on others I can see
both over- and underruns. Both can occur even at the same time on the same PC
as my driver runs in multiple instances and one seems to be a little slow while
another is slightly too fast (on a HP Dual Xeon Workstation). I had no
explanation and so I started digging into the APIs the applications are using
and whether this could be the reason for this behavior. I also wrote a little
application myself that can handle all the APIs to check the clocking and do
some bit transparency tests. What I’ve learned from you so far makes me think
it’s not the API itself, but exclusive mode or not. And non exclusive mode
seems to introduce a lot of trouble with its format conversion, its limiter and
its SRC if you expect bit transparency and audio without any glitches for hours
and days. And both is expected as we’re in the field of 24/7 pro audio
broadcasting. So probably I have to recommend our customers to prefer exclusive
mode for this kind of pro audio applications?

Von: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for DMARC)
Gesendet: Mittwoch, 22. August 2018 14:42
An: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Betreff: [wdmaudiodev] Re: AW: Re: AW: Re: bit transparency from app to WDM
audio driver depending from API?

I could better answer your questions if I understood where you were going with
this. Why do you ask? What is your scenario? These don’t really sound like “how
do I write a driver” questions.

In Windows, the burden falls on the application to either invoke their own
micro-sample-rate-converter, or adjust Windows’ built-in
micro-sample-rate-converter (e.g. via the IAudioClockAdjustment API.)

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>> on
behalf of Johannes Freyberger
<jfreyberger@xxxxxxxxxxxxxxxxxxxx<mailto:jfreyberger@xxxxxxxxxxxxxxxxxxxx>>
Sent: Wednesday, August 22, 2018 2:03:14 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] AW: Re: AW: Re: bit transparency from app to WDM audio
driver depending from API?

Thank you very much for this info and the one concerning the exclusive mode for
bit transparency. Is this micro SRC insertion only done in non exclusive mode
or would this also be inserted in exclusive mode, if such a microphone/speaker
situation is detected? Is the SRC factor only computed once or dynamically
adjusted? I’m thinking about a situation where you have a playout system
running multiple hours or even days and if the SRC wouldn’t be adjusted or
extremely precise it probably would result in buffer under- or overruns on any
end after a while.

Does this information concerning exclusive mode, SRC etc. apply to all Windows
OS versions (saying all I think about Windows 7, 8, 8.1, 10 64 bit and Windows
Server 2102 and 2016)?
____________________________________________________

„Usually a micro SRC is only inserted if the application in question has to
connect two clocks.
If it’s just music playback, then the whole clock is driven by the DAC. If the
effective sample rate is a little slow, then the music just takes a little
longer to play.
But if the microphone and the speaker are both involved, and the ADC and DACs
are at different effective sample rates, then yes, a micro SRC is (hopefully!)
inserted.”

Follow-Ups:
- [wdmaudiodev] AW: Re: AW: external audio driver clocking
  - From: Johannes Freyberger

References:
- [wdmaudiodev] AW: external audio driver clocking
  - From: Johannes Freyberger

[wdmaudiodev] Re: AW: external audio driver clocking

Other related posts: