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 <wdmaudiodev-bounce@xxxxxxxxxxxxx> Im
Auftrag von Matthew van Eerde (Redacted sender "Matthew.van.Eerde" for
Gesendet: Mittwoch, 22. August 2018 18:24
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?
<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.)
<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx> > on behalf of Johannes Freyberger
Sent: Wednesday, August 22, 2018 2:03:14 AM