[wdmaudiodev] Re: kernel streaming and format negotiation
- From: Philip Lukidis <PLukidis@xxxxxxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Tue, 21 Feb 2006 15:10:54 -0500
Well, I actually found an answer in an unexpected post in the archives
(which explains why I missed it before):
//www.freelists.org/archives/wdmaudiodev/05-2003/msg00054.html
Walter Oney determined this answer.
I also found two "alternates":
a) When IRP_MJ_CREATE completes, in DriverContext[0] there is an SRB (as the
lower driver is a streaming minidriver) for SRB_OPEN_STREAM. Within it,
pSrb->CommandData->OpenFormat is a KSDATAFORMAT member of the accepted
format (assuming the SRB was succeeded). I'm not crazy about this approach
because it depends on the lower driver being a streaming minidriver. If it
was changed to a avstream driver this would fail, I think (though I'm not
very familiar with avstream).
b) Another cludge: KsValidateConnectRequest returns a KSPIN_CONNECT
structure, followed by a KSDATAFORMAT structure. The KSPIN_DESCRIPTOR for
this call can be found from scrounging in FsContexts...in the IRP_MJ_CREATE
stack location, there is FileObject, which has a RelatedFileObject member.
Within the RelatedFileObject's FsContext, at an offset of 12 pointers, is a
KSPIN_DESCRIPTOR. I could not find a KSDATAFORMAT in any FsContext, though.
An extreme caveat: KsValidateConnectRequest crashes when I call it from my
IRP_MJ_CREATE dispatch routine, but if I call it from the IRP_MJ_CREATE
completion routine it works fine (and the parameters I pass, are, AFAIK the
same). Does anyone know why?
None of these approaches seems very resilient in the long term, so does
anyone else have any suggestions?
And can anyone suggest why KsValidateConnectRequest crashes when I call it
with the exact same parameters from the IRP_MJ_CREATE completion routine,
but crashes when I call it from my IRP_MJ_CREATE dispatch routine? As far
as I see I'm meeting the requirements of KsValidateConnectRequest in both
calls. I suppose the FsContexts in the Irp passed to
KsValidateConnectRequest could be acted on by ks.sys by the time the
completion routine fires, but other than that I don't see a difference
between either calls.
thanks,
Philip Lukidis
> -----Original Message-----
> From: Philip Lukidis
> Sent: Tuesday, February 21, 2006 11:34 AM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: kernel streaming and format negotiation
>
>
> Hello. I'm writing a kernel streaming (upper) filter driver,
> which will operate only with a very constrained list of
> hardware. I'm having trouble determining the negotiated
> KSDATAFORMAT in the streaming filter driver.
> KSPROPERTY_PIN_DATAINTERSECTION does not seem to help me,
> because the last logged completion routine from the function
> driver below the filter always returns a different format
> than the one ultimately selected. What I mean is (grossly
> speaking) that the last logged call of
> KSPROPERTY_PIN_DATAINTERSECTION requests a match to rangeX (1
> range only), but the filter completion routine indicates that
> the function driver has filled in the output buffer with
> rangeY as the result. Yet rangeX is seen to be the
> negotiated format. For each call to
> KSPROPERTY_PIN_DATAINTERSECTION, there is only 1 format sent
> (along with its pin, KSMULTIPLE_ITEM specifying 1 range).
> Yet the function driver does not always return a match for
> it. Why is this?
>
> Also, sometimes the IRP information member in the completion
> routine shows extended format data has been returned, with
> STATUS_SUCCESS, yet I see mostly zero/garbage within the
> output buffer (both in my traces and in the debugger). Why
> would that be? I look both in the user output buffer (
> Irp->UserBuffer, in in a try except block), and a kernel
> mapping of the output buffer which I lock and map myself when
> the IRP is first coming down the stack, and both show the
> same garbage. In any case, during these cases
> Irp->PendingReturned is always 0. Why would the function
> driver sometimes return invalid data? Or am I tapping this
> communication (METHOD_NEITHER IOCTLs) incorrectly?
>
> Also, KSPROPERTY_PIN_CONSTRAINEDDATARANGES,
> KSPROPERTY_PIN_PROPOSEDATAFORMAT,
> KSPROPERTY_CONNECTION_DATAFORMAT and
> KSPROPERTY_CONNECTION_PROPOSEDATAFORMAT are never logged by
> the filter driver.
>
> I know that I'm missing something here, could something shed
> any light on how a kernel streaming filter could find out
> about the negotiated format?
>
> thanks,
>
> Philip Lukidis
>
******************
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:
