[wdmaudiodev] Re: More Kernel Streaming confusion.
- From: Max K <xaseriii@xxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Sun, 23 Jun 2013 12:10:21 +0200
Hi Jeff,
thanks for your mail, it all got a bit clearer now. I used to look more at the
Dmus side of KS where things didn't seem to fit the purpose, but looking at the
way a wave audio card works the concept makes more sense.
I guess I will keep trying a bit to get custom Pins working and see where I get
to.
Regards,
Max
> From: barefeet@xxxxxxxxxxxxxx
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] Re: More Kernel Streaming confusion.
> Date: Sun, 23 Jun 2013 10:25:51 +1000
>
> Hi Max,
>
> PortCls is principally used to represent audio devices that use DMA to
> transfer the audio to and from the hardware. In that respect, the drivers
> don't get involved in the actual transfer of audio (with one exception), as
> the hardware's DMA engine takes care of that, so try not to think of audio
> "passing through" any of it.
>
> A PortCls driver has two components, a wave port and a topology port. The
> wave port is primarily responsible for setting up the DMA parameters,
> setting sampling rates and bit depths, and starting and stopping the
> streams. There are currently three flavours of wave ports - WaveCyclic (the
> oldest), WavePCI and WaveRT. WaveCyclic requires the driver to copy the
> audio data to and from the kernel-space DMA buffers (this is the exception I
> mentioned above), whereas WavePCI and WaveRT set up DMA transfers directly
> to and from user-space buffers. WaveRT is the preferred model but is only
> supported on Vista and later systems.
>
> The topology port is where the hardware's audio controls are represented,
> and this is where the nodes come in. Each node represents one of the
> hardware's physical controls, such as faders, mutes, multiplexers, mixers
> and peak meters. Note that these are hardware controls - the driver's
> topology port doesn't (or shouldn't) go anywhere near the audio data. The
> controls are adjusted using property set calls, which are typically used to
> write to or read from hardware registers. The driver creates a
> PCFILTER_DESCRIPTOR structure that describes how the various controls are
> connected together - this is where the pins, nodes and connections come in.
>
> The topology port provides the back-end functionality that applications see
> through the Mixer API or the corresponding Core Audio interfaces such as
> IDeviceTopology, although each of these APIs has a different way of
> describing the topology (more confusion!).
>
> Windows provides the top-level wave port and topology port objects, which
> communicate with driver-supplied hardware-specific miniports. Like much
> kernel code, it's hard to see the forest for the trees, and the best way to
> learn is to actually write a driver for some hardware, using one of the
> sample drivers as a starting point.
>
> I hope that's of some help to you. Have a look at the "Introduction to Port
> Class" section of the WDK documentation, particularly the diagrams. The
> documentation does seem to lack a beginner's entry point and can be rather
> daunting and confusing when you don't have a clear mental picture of how it
> all hangs together, and a lot of it refers to the pre-Vista systems which
> got superseded by the later OS's audio engine and endpoint-centric
> architecture. I think writing a driver (preferably for some real hardware)
> and poking around in it with windbg is about the only way to get a good
> handle on how it all works.
>
> Jeff
>
>
> From: Max K
> Sent: Sunday, June 23, 2013 5:01 AM
> To: wdmaudiodev@xxxxxxxxxxxxx
> Subject: [wdmaudiodev] More Kernel Streaming confusion.
>
> Hi,
>
> over the time, I got more and more insight in KS, but worryingly, things
> didn't become clearer but more confusing. It would be great if somebody
> could give a short explanation to the questions I have.
>
> If I'm correct, PortCL is just a "sub-framework" to make driver construction
> easier, by reducing the amount of ks code that needs to be written.
> However does this mean that I am also restricted in KS functionality by
> using portCL?
> For example, I read on MSDN that usually Pins are instantiated using
> createFile and interfaces with using DeviceIoControl, however I don't see
> how to properly implement a custom pin with a generic datarange in a portcl
> minidriver (its even worse documented in the MSDN than MIDI).
>
> Then there is the question: what do I need nodes and connections for? It
> would make perfectly sense, if the data was passed along the connections and
> each node hat a data processing function, but the only reason sample driver
> seem to have nodes for are to handle Property Requests.
>
> Data isn't passed through the filter, its passed to a stream that is
> connected to the pin which either stores it internally or in the Miniport.
> What happens there is completely up to the miniport.
>
> It may well be that I'm talking nonsense here but that's how I currently
> perceive Kernel Streaming.
>
> Regards,
> Max
>
> ******************
>
> 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:
