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

  • From: "Johannes Freyberger" <jfreyberger@xxxxxxxxxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 22 Aug 2018 15:19:44 +0200

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

Other related posts: