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/ >