KMDF or WDM for iso usb streaming?

[ross_d]

Hi,

I’m new to writting drivers and still at the stage of design where I am trying to understand my options and path. I’ve found this thread here:

http://www.osronline.com/showThread.cfm?link=145406

…which I think helps answers my question on my initial step. However, I would like to verify / clarify before choosing a framework and example to build upon.

I have a device with an FX2 chip for which the firmware configures the interface with two bulk and two iso endpoints for streaming audio (in both directions). The device operates at high speed (it must for low latency).

UMDF and usbaudio.sys are appartently not an option for me, and it appears I must write a kernel mode function driver which sits between the bus driver and AVStream / KS. Initially I looked at usbsamp driver in the src\kmdf directory, but had little luck with it (and lots of crashes). However isousb WDM driver in the src\usb dir seems to be more readily suited and already includes streaming methods. The thread above seems to suggest what I learned the hard way: KMDF isn’t suitable for streaming audio?

So my questions are:

1. Is the WDM isousb example indeed my best (or only) starting point? The code doesn’t look any more complex than the KMDF example… what am I missing out on with KMDF?
2. It appears the example was at one time OSR FX2 example also?, though it says intended for intel chip, seems otherwise generic. Are there additional OSR (or other) code examples (modifictions of isousb) that would be helpful to implement streaming?
3. Once I get the isousb FDO working and tested, what is my next step in implementing the “AVStream driver” mentioned in the above thread? I’m guessing DirectSound is not optional, and I’ll have to shimmy in ASIO later on.

[Tim_Roberts]

xxxxx@gmail.com wrote:

I have a device with an FX2 chip for which the firmware configures the interface with two bulk and two iso endpoints for streaming audio (in both directions). The device operates at high speed (it must for low latency).

UMDF and usbaudio.sys are appartently not an option for me,…

UMDF is not an option, but why do you discard usbaudio.sys? Seriously,
your best option BY FAR is to tweak the firmware so you meet the USB
Audio Class spec. By doing so, you don’t need to write a driver at
all. It’s not hard; if you can already pump audio out of an isochronous
pipe, you are most of the way there.

Your next best option is to write a lower filter to usbaudio.sys to make
your device LOOK like it meets the spec. Rewrite the descriptors so
your isochronous interface appears as the Audio Streaming interface, and
create an Audio Control interface out of whole cloth. I’ve done this
twice for audio devices that only had streaming output.

Microsoft has put 12 years of effort, tuning, testing, and enhancing
into usbaudio.sys. You are really doing yourself a disservice if you
try to start over from scratch.

and it appears I must write a kernel mode function driver which sits between the bus driver and AVStream / KS. Initially I looked at usbsamp driver in the src\kmdf directory, but had little luck with it (and lots of crashes). However isousb WDM driver in the src\usb dir seems to be more readily suited and already includes streaming methods. The thread above seems to suggest what I learned the hard way: KMDF isn’t suitable for streaming audio?

It is POSSIBLE to use KMDF in an streaming driver, by using the miniport
mode. In my own personal opinion, it’s not worth the effort. AVStream
already provides most of what KMDF brings to the party. Plus, the KMDF
continuous reader still doesn’t do isochronous.

So my questions are:

1. Is the WDM isousb example indeed my best (or only) starting point? The code doesn’t look any more complex than the KMDF example… what am I missing out on with KMDF?

What you would need to do is graft the USB parts of the isousb driver
onto the bottom of some audio sample, like avshws or avsamp or msvad.

2. It appears the example was at one time OSR FX2 example also?, though it says intended for intel chip, seems otherwise generic. Are there additional OSR (or other) code examples (modifictions of isousb) that would be helpful to implement streaming?

Isousb has always been for some strange Intel demo board, but the device
itself is really irrelevant. It’s a USB device. It has descriptors and
endpoints.

3. Once I get the isousb FDO working and tested, what is my next step in implementing the “AVStream driver” mentioned in the above thread? I’m guessing DirectSound is not optional, and I’ll have to shimmy in ASIO later on.

DirectSound and ASIO are strictly user-mode concepts. Once you have
your kernel streaming driver, all of those things will Just Work.

However, to repeat myself, you need to take a step back and figure out
how you can transmogrify your device into something that works with
usbaudio.sys. That is required if you ever plan to get a logo; an audio
device on USB must be a true Audio Class device in order to get the logo.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[ross_d]

Thanks very much Tim,

That’s perhaps the most concise and straightforward info I’ve gotten from any doc, book or forum thus far

UMDF is not an option, but why do you discard usbaudio.sys?

Well, pardon my ignorance, but IIRC, the docs stated that it doesn’t support 24-bit PCM… Or maybe it’s just the docs are outdated? The device must be very low latency, 2 channels of 24-bit PCM in both directions and MIDI, and I need full control over sample rate / bit rate / buffer sizes, etc. I don’t mind modifying the fw if possible / necessary, and I’ll definitely revisit usbaudio if it doesn’t lead me down another blind alley.

Unfortunately it seems the limitations of each option / framework / etc. are at best footnotes in the documentation… “Oh, and BTW, UMDF doesn’t support isochronous transfers… Oh, and BTW, you can’t do isochronous streaming with KMDF either, and Oh, BTW, no 24-bit PCM with usbaudio.sys”. I guess it doesn’t hurt to read the whole DDK (and everything MS Press on the subject), but a little “feature comparison chart” wouldn’t hurt

Anyway, sorry for the little beginners frustration rant… I do appreciate the help

[Tim_Roberts]

xxxxx@gmail.com wrote:

> UMDF is not an option, but why do you discard usbaudio.sys?
>

Well, pardon my ignorance, but IIRC, the docs stated that it doesn’t support 24-bit PCM… Or maybe it’s just the docs are outdated?

Which docs? The USB Audio Class specification certainly supports 24-bit
PCM, and I thought usbaudio.sys implemented virtually the complete
spec. I’m not doubting you – there are those who claim I have been
wrong once or twice – but I’d like to see what you saw.

Do you have the USB Audio Class spec? The data formats are in a
separate document.

The device must be very low latency, 2 channels of 24-bit PCM in both directions and MIDI, and I need full control over sample rate / bit rate / buffer sizes, etc. I don’t mind modifying the fw if possible / necessary, and I’ll definitely revisit usbaudio if it doesn’t lead me down another blind alley.

Usbaudio.sys isn’t going to introduce any latency that isn’t already
inherent in a USB device. It is, after all, a protocol bus rather than
a real-time wire. Usbaudio.sys creates its URBs to handle 10ms at a
time. Your device can advertise any number of different available
formats in its descriptors. However, you don’t get any control over
buffer sizes. That’s all determined by the driver. Generally, once you
start streaming, the delay is constant, and the stream is continuous.

What do YOU mean when you say “low latency”? That phrase means many
different things to different people.

MIDI requires a separate interface, which means separate endpoints. You
can’t mix audio and MIDI endpoints in a single interface. That’s a
potential problem for the FX2, because you only have 4 endpoints.

What are you building? MIDI doesn’t come up all that often.

Unfortunately it seems the limitations of each option / framework / etc. are at best footnotes in the documentation… “Oh, and BTW, UMDF doesn’t support isochronous transfers… Oh, and BTW, you can’t do isochronous streaming with KMDF either, and Oh, BTW, no 24-bit PCM with usbaudio.sys”. I guess it doesn’t hurt to read the whole DDK (and everything MS Press on the subject), but a little “feature comparison chart” wouldn’t hurt

This is a fair complaint. Perhaps my biggest issue with the WDK docs is
the lack of what I would call real-world guidance. The docs are very
good at describing everything that is available under the sun, usually
in great detail, with all of the APIs and properties and options and
interfaces and methods and exceptions etc ad nauseum. However, it is
very difficult to find a document that says “OK, folks if you want to
create an audio driver, here are the 5 most important things you need to
implement. Everything else can wait for later.” Most of that has to be
learned by painful experience.

We are starting to get a lot of that kind of practical knowledge in the
blogs from the WDK team, and I treasure those articles.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[ross_d]

> Which docs? The USB Audio Class specification certainly supports 24-bit PCM, and I thought usbaudio.sys implemented virtually the complete spec. I’m not doubting you – there are those who claim I have been wrong once or twice – but I’d like to see what you saw.

It seems I may have misinterpreted this nugget of technical writing gold from the WDK docs:

“In Windows 98 Second Edition (SE), Windows Me, and Windows 2000 and later, USBAudio supports all the same features as Windows 98, with one exception: USBAudio supports WAVEFORMATEXTENSIBLE but does not support packed WAVE_FORMAT_PCM for 24-bit data.”

Apparently I should look into the former

What do YOU mean when you say “low latency”? That phrase means many different things to different people.

true, fair enough. As a guide, the driver needs to work with high end audio applications. Typically in these applications, you select a driver interface (DS or ASIO), a sample rate, and buffer size. In this context the latency refers to the user mode applications ability to process the block of data within a specific period of time (defined by the buffer size / sample rate). If the application cannot process the audio data before the next block arrives from the driver, packets will be dropped and the audio stream will be interrupted (at best).

So, I’ll admit, this is still a source of some confusion for me… if the inherent latency of usbaudio.sys (and the required drivers above and below?) is 10ms… how does this affect the latency the DS or ASIO interfaces are able to provide to the app? Obviously, the faster the data makes the trip; device->app->device, the better, and the app is responsible for it’s part, but the latency I refer to is that that is introduced by the driver and thus limiting the options / capabilities of the interface exposed to the app. I imagine it is primarily this latency that prevents UMDF and perhaps KMDF from supporting isochronous streaming? Otherwise, why not support it?

MIDI requires a separate interface, which means separate endpoints. You can’t mix audio and MIDI endpoints in a single interface. That’s a potential problem for the FX2, because you only have 4 endpoints.

Hrm, that concerns me What are my options here? The two bulk are only being used for commands. Can those be “mixed” somehow?

We are starting to get a lot of that kind of practical knowledge in the blogs from the WDK team, and I treasure those articles.

I have them bookmarked… I figured I wasn’t ready yet to digest what initially appears to be advanced information

As a side question, a recent source of curiosity: I’ve been using a VMWare target machine to get accustomed to KM debugging. When plugging in the device, VMWare shows it as “Cypress Audio” in the list of devices I can connect to the target. Now, no inf file I’ve written or seen has ever named the device “Cypress Audio”… which begs the question: What does VMWare know that I (and Windows) does not? Probably it has it’s own inf which corresponds to the default VID/PID used by the chip in renumeration? Perhaps the way the device is setup is already somehow compliant with the Audio Class? Or just a fluke.

Anyway, thx again, I’ll take a closer look at usbaudio.sys, would be great if it can help reduce development time for this device

[Ken_Johnson]

I think that VMware probably has its own internal database of VID to textural vendor names to display for their GUI.

• S

-----Original Message-----
From: xxxxx@gmail.com
Sent: Thursday, July 02, 2009 20:12
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF or WDM for iso usb streaming?

> Which docs? The USB Audio Class specification certainly supports 24-bit PCM, and I thought usbaudio.sys implemented virtually the complete spec. I’m not doubting you – there are those who claim I have been wrong once or twice – but I’d like to see what you saw.

It seems I may have misinterpreted this nugget of technical writing gold from the WDK docs:

“In Windows 98 Second Edition (SE), Windows Me, and Windows 2000 and later, USBAudio supports all the same features as Windows 98, with one exception: USBAudio supports WAVEFORMATEXTENSIBLE but does not support packed WAVE_FORMAT_PCM for 24-bit data.”

Apparently I should look into the former

> What do YOU mean when you say “low latency”? That phrase means many different things to different people.

true, fair enough. As a guide, the driver needs to work with high end audio applications. Typically in these applications, you select a driver interface (DS or ASIO), a sample rate, and buffer size. In this context the latency refers to the user mode applications ability to process the block of data within a specific period of time (defined by the buffer size / sample rate). If the application cannot process the audio data before the next block arrives from the driver, packets will be dropped and the audio stream will be interrupted (at best).

So, I’ll admit, this is still a source of some confusion for me… if the inherent latency of usbaudio.sys (and the required drivers above and below?) is 10ms… how does this affect the latency the DS or ASIO interfaces are able to provide to the app? Obviously, the faster the data makes the trip; device->app->device, the better, and the app is responsible for it’s part, but the latency I refer to is that that is introduced by the driver and thus limiting the options / capabilities of the interface exposed to the app. I imagine it is primarily this latency that prevents UMDF and perhaps KMDF from supporting isochronous streaming? Otherwise, why not support it?

> MIDI requires a separate interface, which means separate endpoints. You can’t mix audio and MIDI endpoints in a single interface. That’s a potential problem for the FX2, because you only have 4 endpoints.

Hrm, that concerns me What are my options here? The two bulk are only being used for commands. Can those be “mixed” somehow?

> We are starting to get a lot of that kind of practical knowledge in the blogs from the WDK team, and I treasure those articles.

I have them bookmarked… I figured I wasn’t ready yet to digest what initially appears to be advanced information

As a side question, a recent source of curiosity: I’ve been using a VMWare target machine to get accustomed to KM debugging. When plugging in the device, VMWare shows it as “Cypress Audio” in the list of devices I can connect to the target. Now, no inf file I’ve written or seen has ever named the device “Cypress Audio”… which begs the question: What does VMWare know that I (and Windows) does not? Probably it has it’s own inf which corresponds to the default VID/PID used by the chip in renumeration? Perhaps the way the device is setup is already somehow compliant with the Audio Class? Or just a fluke.

Anyway, thx again, I’ll take a closer look at usbaudio.sys, would be great if it can help reduce development time for this device

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

[Tim_Roberts]

On Thu, Jul 02, 2009 at 11:12:36PM -0400, xxxxx@gmail.com wrote:

It seems I may have misinterpreted this nugget of technical writing gold
from the WDK docs:

"In Windows 98 Second Edition (SE), Windows Me, and Windows 2000 and
later, USBAudio supports all the same features as Windows 98, with one
exception: USBAudio supports WAVEFORMATEXTENSIBLE but does not support
packed WAVE_FORMAT_PCM for 24-bit data."

Apparently I should look into the former

Hmmm. I wonder if that's written backwards. It seems odd that a particular
format would be dropped after the first release.

true, fair enough. As a guide, the driver needs to work with high end audio applications. Typically in these applications, you select a driver interface (DS or ASIO), a sample rate, and buffer size. In this context the latency refers to the user mode applications ability to process the block of data within a specific period of time (defined by the buffer size / sample rate). If the application cannot process the audio data before the next block arrives from the driver, packets will be dropped and the audio stream will be interrupted (at best).

So, I'll admit, this is still a source of some confusion for me... if
the inherent latency of usbaudio.sys (and the required drivers above
and below?) is 10ms... how does this affect the latency the DS or ASIO
interfaces are able to provide to the app?

In XP, ALL of the audio devices try to do their data in 10ms chunks, so
USBAudio is not at any particular disadvantage.

I imagine it is primarily this latency that prevents UMDF and perhaps
KMDF from supporting isochronous streaming? Otherwise, why not support it?

Not at all. They don't support it because (a) it's not trivial, and
(b) no one has asked for it. Well, no one with a provable need.
Isochronous is just not all that common, except for audio and video, where
people use other driver models.

Hrm, that concerns me What are my options here? The two bulk are only
being used for commands. Can those be "mixed" somehow?

You could run all your commands through the control endpoint. That's more
traditional. That will be required if you make yourself USB Audio Class
compliant.

As a side question, a recent source of curiosity: I've been using a
VMWare target machine to get accustomed to KM debugging. When plugging
in the device, VMWare shows it as "Cypress Audio" in the list of devices
I can connect to the target. Now, no inf file I've written or seen
has ever named the device "Cypress Audio"...

Is it possible this is coming from the string descriptors in your device?

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

[Praveen_Rao]

>> I guess it doesn’t hurt to read the whole DDK (and everything MS Press on the subject), but a little “feature comparison chart” wouldn’t hurt

This is a fair complaint. Perhaps my biggest issue with the WDK docs is the lack of what I would call real-world guidance.

FWIW, there is a “Choosing driver model” article on WHDC

http://www.microsoft.com/whdc/driver/foundation/DrvRoadmap.mspx#

I can’t say that it covers every detail but the plan is to enhance this doc and integrate it in WDK so that there is guidance on choosing a driver model.

It can then be refined further based on community’s feedback.

Thanks,
Praveen

[ross_d]

Unfortunately got sidetracked with another project, but have had some time to review usbaudio and Audio Class / UAA stuff… seems a viable option for us, and I’m not ruling out “tweaking” the firmware but there are other factors there.

Your next best option is to write a lower filter to usbaudio.sys to make your device LOOK like it meets the spec. Rewrite the descriptors so your isochronous interface appears as the Audio Streaming interface, and create an Audio Control interface out of whole cloth.

Conceptually this makes sense… I imagine I can suss out the impl. with further study, but I don’t suppose there are specific WDK docs / examples for this particular approach that would help me get started?

I’ve done this twice for audio devices that only had streaming output.

This is not to say that it won’t work for streaming input as well, is it?

[Tim_Roberts]

xxxxx@gmail.com wrote:

Unfortunately got sidetracked with another project, but have had some time to review usbaudio and Audio Class / UAA stuff… seems a viable option for us, and I’m not ruling out “tweaking” the firmware but there are other factors there.

Yes, there always are…

> Your next best option is to write a lower filter to usbaudio.sys to make your device LOOK like it meets the spec. Rewrite the descriptors so your isochronous interface appears as the Audio Streaming interface, and create an Audio Control interface out of whole cloth.
>

Conceptually this makes sense… I imagine I can suss out the impl. with further study, but I don’t suppose there are specific WDK docs / examples for this particular approach that would help me get started?

No, it’s too problem-specific. There are certainly samples of KMDF
filter drivers that you could use as a base, but the USB magic all has
to be worked out on your own. You’re basically pretending to be a USB
device.

> I’ve done this twice for audio devices that only had streaming output.
>

This is not to say that it won’t work for streaming input as well, is it?

Nope, it should be exactly the same. You’re just doing plumbing.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[ross_d]

> You’re basically pretending to be a USB device.

heh, in order to pretend to be a USB device I’ll also have to pretend to know what I’m doing

I wonder if this is really the best option for a newbie to do blind? At least if I do things the “hard way” ~isousb.sys->avstream there is a ~defined path with ~documentation and ~examples…

however, this won’t be the first USB audio device I’ll be tasked with so perhaps it’s best to bite the bullet and “conform” now and save myself (and the hardware guy) some headaches in the future.