[wdmaudiodev] Re: bit transparency from app to WDM audio driver depending from API?

From: "Matthew van Eerde" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "Matthew.van.Eerde" for DMARC)
To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
Date: Wed, 22 Aug 2018 16:24:25 +0000

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 <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
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.”

References:
- [wdmaudiodev] Re: bit transparency from app to WDM audio driver depending from API?
  - From: Johannes Freyberger

[wdmaudiodev] Re: bit transparency from app to WDM audio driver depending from API?

Other related posts: