[wdmaudiodev] Re: AVStream virtual audio driver: different sound quality dependently on the number of CPU cores.

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 22 Jul 2016 11:43:36 -0700

Alexander Ivash wrote:

If this is just a timing issue (although not clear why it doesn't
appear on all the environments) - I'll try to play with delays etc.
Just to check if it makes any difference. And if it makes, I have
another question: using my current approach, what should I do if
Windows is asking me for the data but it is not 'right' time to
provide it? Just specify BytesUsed = 0 and Terminate = false ? Or such
approach will not work at all and I have to return to DPC-based
approach where DPC was doing KsAttemptProcessing at the 'right' time?

I think you have the somewhat common misconception that all of your
processing has to happen in the Process callback.  That isn't so
(although sometimes it makes things easier).  Process gets called when a
new, empty buffer is presented to your driver.  It isn't asking you for
data.  It's just letting you know that more buffer space has arrived. 
The buffer gets added to your stream's "trailing edge".  You don't
actually have to do anything with it at that time.  In fact, because
streaming apps like to buffer ahead, it's quite common for you to get
three or four empty buffers queued up before you deliver anything.  In
my USB camera driver for example, the Process callback looks essentially
like this:

    NTSTATUS CCapturePin::Process()
    {
        return STATUS_PENDING;
    }

Later, when I do get data (typically in a the completion routine for a
USB request), I go fetch the leading edge from the stream, copy data in,
and advance the leading edge.  THAT'S what tells the framework that you
have delivered data.

So, assuming you go with a timed approach, you'd do your processing in
the timer callback. You COULD call KsAttemptProcessing and do the work
in the Process callback, if you want.

-- 
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

Other related posts: