I wish I've learned this a month ago.. :) I switched back to DPC-based
approach with manual triggering KsAttemptProcessing every 10ms, because
'BytesAvailable' in the ProcessPin always seems to be 1764 (which is 10ms
for 44100/stereo/16bit, correct?) and I noticed the difference in
behavior! Sound seems to be ok most of the time even on 'bad' environment,
although sometimes it 'switches' into 'distorted mode' and then
occasionally switches back to normal. I think this is probably because of
too small frame size. I've tried to increase it by using
DECLARE_SIMPLE_FRAMING_EX and specifying 1764 * 4 as the fame size, but I
still see 1764 as 'BytesAvailable'. What I'm missing this time?
Regards, Alexander
Tim Roberts <timr@xxxxxxxxx> писал(а) в своём письме Fri, 22 Jul 2016
21:43:36 +0300:
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.
