xxxxx@cspeed.com wrote:
I have a few loosely-related questions regarding AVStream dispatch routines on which I could benefit from some clarification:
1.) Am I correct in assuming that there is no inherent synchronization between the AVStrMiniPinProcess callback and the AVStrMiniPinSetDeviceState callback (or any other pin dispatch callbacks, for that matter)? If so, is it safe (in terms of deadlock avoidance) to acquire the pin’s “processing mutex” from within the AVStrMiniPinSetDeviceState routine in order to synchronize the execution of a block of code with the AVStrMiniPinProcess routine, or is it advised to utilize your own dedicated locks for this purpose?
If you have set KSPIN_FLAG_PROCESS_IN_RUN_STATE_ONLY, then your process
callback will not be called until the pin has successfully transitioned
to “run” state, and the pin cannot transition out of “run” state until
your process callback is complete. Without that pin, your process
callback can also be called in “pause” state, which means the transition
to “run” might overlap with processing.
This is usually not an issue. You’re going to do your state setup in
one of those two transitions (acquire->pause or pause->run), so there
won’t be any danger of an overlap.
However, AVStream has three internal mutexes to handle this kind of
thing: one for the device, one for the filter, and one for processing.
If you really need to guarantee that no processing occures in your state
change callback, just grab the processing mutex.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff567745.aspx
2.) Also, allow me to take a step back for a moment and ask a more fundamental question: is it even appropriate to provide an AVStrMiniPinProcess callback for a hardware device that delivers frames into a common buffer and then raises an interrupt? In this case, couldn’t all of the stream processing just be done directly in the interrupt DPC? Is there any reason to add another level of deferral by kicking with KsPinAttemptProcessing and performing the processing in AVStrMiniPinProcess?
You have to provide ONE of the two process callbacks (filter or pin),
but it doesn’t have to do very much. That’s where you learn that a new
buffer is available. In my USB camera AVStream driver, the pin Process
callback is about 6 lines of code. I bump a statistics counter, and
when I receive the very first buffer, I go trigger streaming. All of
the work gets done in the USB completion callback (which is akin to the
interrupt DPC in a PCI device).
Further, in that case, there’s no need to call KsPinAttemptProcessing.
All that does is trigger a call to Process. If Process is empty, then
KsPinAttemptProcessing is pointless. It isn’t going to generate any new
buffers.
3.) The function reference documentation for the AVStream pin dispatch callbacks neglects to remark on the IRQL for a few of the functions. Are there any guarantees about the IRQL for AVStrMiniPinDeviceSetState and AVStrMiniPinSetDataFormat?
You’re right, it is not shown in the documentation. These routines are
called at PASSIVE_LEVEL. As evidence, I ask the jury to examine the
source code in the AVStream samples in the WDK. In both cases, these
routines are paged code. That requires passive.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.