[wdmaudiodev] Re: More Kernel Streaming confusion.

  • From: "Jeff Pages" <barefeet@xxxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • 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.


From: Max K
Sent: Sunday, June 23, 2013 5:01 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] More Kernel Streaming confusion.


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.


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


Other related posts: