[wdmaudiodev] Re: Anybody got any information about the IRPs in an upper filter?
- From: Tim Roberts <timr@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Fri, 16 Oct 2009 13:46:34 -0700
NCH Obble Smith wrote:
>
> May I ask if anyone have a link / information about the IRPs that an
> upper filter must monitor to copy the audio stream.
There are probably better ways to do what you need. What is your real
requirement?
> I know of the existence of IO have read about IRP_MJ_DEVICE_CONTROL
> and IRP_MJ_WRITE / READ
> but I havn't found any information about the format of these IRPs. I
> am assuming theres a command payload in the buffer of the IRP that the
> audio driver would interpret and then send commands to the minidriver.
You don't have to "assume" this. It's all documented.
> I noticed in the inputbuffer the sample rate information e.g.:
> Filter - IRP_MJ_DEVICE_CONTROL
> Filter - Mode:KernelMode
> UserBuffer Address = 0xEDF5C1E8
> Stack Func = 14, 0 Flags(0x00000000)
> Parameters (OutputBufferLength =82, InputBufferLength=24,
> IoControlCode=002F0003 (IOCTL_KS_PROPERTY), Type3InputBuffer=0xEDF5C1C8
> ----------------------------------------------------------------
> 20 C9 58 1D - 9B AC CF 11
> 02 00 00 00 - 02 00 00 00
> 52 00 00 00 - 00 00 00 00
> 61 75 64 73 - 00 00 10 00
> 01 00 00 00 - 00 00 10 00
> 81 9F 58 05 - 56 C3 CE 11
> 01 00 02 00 - *22 56* 00 00
> 00 00 00 00 - 03 00 00 00
> 00 00 00 00 - 00 00 00 00
> A5 90 1C ED - 60 E8 5F 86
> 3C 18
> ---------------------------------
>
It's amusing that you couldn't chase down this information, because it
is all clearly documented. The ioctl code is IOCTL_KS_PROPERTY, which
is documented. The buffer contains a KSPROPERTY and a KSDATAFORMAT.
The property GUID is "1D58C920-...", which is KSPROPSETID_Connection.
The property number is 2, which is KSPROPERTY_CONNECTION_DATAFORMAT,
also well documented. The flags word is KSPROPERTY_TYPE_SET, which
means the caller is trying to set the data format. The rest of this
should be a KSDATAFORMAT.
> but I noticed when first initialized it's
> 60 49 13 8C - AD 51 CF 11
> 04 00 00 00 - 01 00 00 00
> B8 00 00 00 - 02 00 00 00
> 00 00 00 00 - 00 00 00 00
> 80 00 00 AA - 00 38 9B 71
> 80 00 00 AA - 00 38 9B 71
> BF 01 00 AA - *00 55* 59 5A
> 20 00 00 00 - 64 00 00 00
> 58 00 00 00 - 00 00 00 00
> 61 75 64 73 - 00 00 10 00
> 01 00
This is KSPROPSETID_Pin, KSPROPERTY_PIN_DATAINTERSECTION,
KSPROPERTY_TYPE_GET. In this case, the buffer contains a KSP_PIN
structure, followed by a KSMULTIPLE_ITEM and an array of KSDATARANGEs.
The layout of this property is completely different from
KSPROPERTY_CONNECTION_DATAFORMAT.
Here, the caller is communicating with the pin, instead of the filter.
It has received the list of possible data formats that the driver
supports, and here it's trying to narrow down what the pin can actually
do at this time.
> So the does anyone know of a link to the documentation of how the IRP
> to the audio driver works? Or any tips on how to process the IRPs to
> get meaningful information? e.g. Audio format
Remember, you can't say "the" audio driver. There are lots of audio
drivers. Today, your audio drivers are all kernel streaming (KS)
drivers, and use the kernel streaming ioctls to do all of their work.
You will never see IRP_MJ_READ and IRP_MJ_WRITE requests here. Instead,
the format is negotiated using sometimes hundreds of IOCTL_KS_PROPERTY
requests, and data is transfered using the ioctls IOCTL_KS_READ_STREAM
and IOCTL_KS_WRITE_STREAM.
--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Other related posts:
