Writing a UMDF ASIO/Ethernet interface driver possible?

NTDEV
1

Hi there,

I am a newcomer, total newbie in Windows driver development but willing to read/learn whatever is required to achieve my goal. :slight_smile:

We have host applications that generate sound to output via our specific USB Audio device that presently uses our WHQL-certified INF (to customize the device name in Windows and force some default config) and the standard usbaudio.sys driver.

What I want to achieve is write a custom driver that would either wrap or use the current USB Audio device driver (usbaudio.sys). That driver would output sound either to the USB device via ASIO or UDP through the Ethernet adapter that would be selected in a user-mode application to configure that “virtual” device.

I don’t want to reinvent the wheel, I know usbaudio.sys works well and ASIO is user-mode so my driver would need to be user-mode. Would UMDF be appropriate for what I’m trying to achieve? Any pointers on what I should be reading/looking at?

Let me specify that I want a user-mode driver to use ASIO on our own USB Audio device while allowing the audio stream to be output via UDP through Ethernet if the user desires so. Again, I don’t seek to reinvent the wheel but have a “virtual” device act as a wrapper that would either drive our USB Audio device via ASIO to usbaudio.sys or UDP through an existing Ethernet driver.

Hints, suggestions, etc. are all welcome!
Many thanks in advance.
Alex

2

Hmmm… Sounds fun, but rather unusual: ASIO (which I usually think of as specifically designed for low latency) *and* remote redirection of audio via UDP (which would entail HIGH latency).

The real question is what abstraction you want to raise for the remote device. Is the remote device a USB device? Do you want to dynamically switch between local USB and this remote device?

Peter
OSR

3

On Wed, Apr 21, 2010 at 11:42 PM, wrote:
> Hmmm… Sounds fun, but rather unusual: ASIO (which I usually think of as specifically designed for low latency) and remote redirection of audio via UDP (which would entail HIGH latency).

UDP latency in a LAN is orders of magnitude lower than the hardware
soundcard latency, even for good hardware. Less then 10ms is very very
good for sound, while UDP latency in a LAN is usually lower then 1ms.

–
Aram Hăvărneanu

4

Hello,

You’re right, in the case of driving the local USB Audio device, there would be low latency through ASIO, as opposed to high latency via UDP. I’m fine with that.

To answer your question, the device receiving the UDP packet would be unknown. The objective would be to redirect the audio via UDP through an Ethernet controller selected by a user-mode control panel. It could be a broadcast or targeted to a specific IP address. It doesn’t matter right now.

Dynamic switching wouldn’t be a requirement even though it would be nice. Actually, I don’t know yet the amount of effort all of this would require. This is what I’m trying to evaluate first.

I know there are already some ASIO for WDM user-mode drivers around such as ASIO4ALL, but I want to develop a custom solution which would allow me to do some trivial processing such as resampling to the desired sample rate, etc. UMDF allows using the Win32 API and write in C++ so it’s to my understanding that it’s way easier and less “dangerous” than writing a KMDF driver.

Where should a newbie like me start? :slight_smile:
Thanks,
Alex

5

“UDP latency in a LAN is orders of magnitude lower than the hardware
soundcard latency, even for good hardware. Less then 10ms is very very
good for sound, while UDP latency in a LAN is usually lower then 1ms.”

Actually, you’re right, but whether latency is low or high over UDP is of no importance to me. The most important part is to achieve lowest latency to our USB Audio device.

Thanks,
Alex

6

I wouldn’t use UMDF. Ideally, you’d like to mix your ASIO streams with audio coming from the other Windows APIs (assuming the sample rates as consistent). I’m not sure how you’d achieve this with UMDF. Even if this isn’t a requirement, your company has already spent a non-trivial amount of time getting the kernel-mode audio driver to work. I’d want to leverage that effort.

ASIO drivers are user-mode COM objects, so the big question is how you want to access the audio and network drivers. For the networking side of things I’d plan on using the standard windows application-level networking functions from within the ASIO code. I don’t think you’re going to be able to get extremely low-latency out of this path regardless of what you do short of writing a custom network device driver (and possibly not even that unless you plan on using QoS functions separate from the rest of the network stack), so you might as well keep things simple. If you don’t need to worry about receiving audio, however, and you’re not overly concerned about latency, I have no doubt that you should be able to get something like this to work even with small ASIO buffer sizes.

The audio device path is a little more complicated. In the past, I’ve typically had my kernel-mode driver expose custom ioctls that the ASIO library would use, but another possibility would be to write your ASIO code to use the user-mode kernel streaming functionality. I’ve seen good results with this design in conjunction with USB audio devices, and it avoids a lot of ring 0 nastiness. There is a free ASIO plugin called ASIO4All that does precisely this.

If you haven’t done so already, you should download the ASIO SDK from Steinberg. Unfortunately, user-mode kernel streaming has always been a little under-documented, and Microsoft seems to be purging what little existed. If you look around, you should be able to find some sample code, though.

-John

On Apr 21, 2010, at 1:05 PM, xxxxx@gmail.com wrote:

Hi there,

I am a newcomer, total newbie in Windows driver development but willing to read/learn whatever is required to achieve my goal. :slight_smile:

We have host applications that generate sound to output via our specific USB Audio device that presently uses our WHQL-certified INF (to customize the device name in Windows and force some default config) and the standard usbaudio.sys driver.

What I want to achieve is write a custom driver that would either wrap or use the current USB Audio device driver (usbaudio.sys). That driver would output sound either to the USB device via ASIO or UDP through the Ethernet adapter that would be selected in a user-mode application to configure that “virtual” device.

I don’t want to reinvent the wheel, I know usbaudio.sys works well and ASIO is user-mode so my driver would need to be user-mode. Would UMDF be appropriate for what I’m trying to achieve? Any pointers on what I should be reading/looking at?

Let me specify that I want a user-mode driver to use ASIO on our own USB Audio device while allowing the audio stream to be output via UDP through Ethernet if the user desires so. Again, I don’t seek to reinvent the wheel but have a “virtual” device act as a wrapper that would either drive our USB Audio device via ASIO to usbaudio.sys or UDP through an existing Ethernet driver.

Hints, suggestions, etc. are all welcome!
Many thanks in advance.
Alex

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

7

> Let me specify that I want a user-mode driver to use ASIO on our own USB Audio device while

allowing the audio stream to be output via UDP through Ethernet if the user desires so.

What is the need of this? write an UDP/RTP driver as a user-mode DLL, will be second, another device.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

8

“will be second, another device.”

To Maxim: I don’t quite understand what you mean by that. Are you saying that you suggest I write a UMDF driver and use the ASIO SDK from there to achieve low latency kernel audio streaming, and from that driver, implement UDP/RTP transfer? If so, that’s exactly what I planned on doing initially.

I’m seeking advice on what I should be reading first to achieve that goal. The most important part to nail down would be the ASIO integration into the custom UMDF driver I’ll be developing. UDP/RTP is secondary.

Thanks,
Alex

9

No, UMDF is not involved in here at all:
You could write an ASIO “driver” dll. The term “driver” might be
misleading since this is just a user mode dll, but Steinberg calls it
so. You simply interface the network stack from that user mode dll.
That becomes the selectable “driver” from your DAW. I also don’t see
how any other USB drivers you already have could simplify anything
here.

DAW <-> your ASIO driver (to be written) <-> network stack

best,
Hagen.

On Thu, Apr 22, 2010 at 5:58 PM, wrote:
> “will be second, another device.”
>
> To Maxim: I don’t quite understand what you mean by that. Are you saying that you suggest I write a UMDF driver and use the ASIO SDK from there to achieve low latency kernel audio streaming, and from that driver, implement UDP/RTP transfer? If so, that’s exactly what I planned on doing initially.
>
> I’m seeking advice on what I should be reading first to achieve that goal. The most important part to nail down would be the ASIO integration into the custom UMDF driver I’ll be developing. UDP/RTP is secondary.
>
> Thanks,
> Alex
>
> —
> 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
>

–
___________________
dynamic acoustics e.U.
Weyringergasse 37/3/11a
1040 Vienna / Austria
+43 680 1268 751

VAT: ATU65049413
FN: 326751t
IBAN: AT463200000010353811
BIC: RLNWATWW

10

John,

ASIO4ALL is precisely what I’m trying to accomplish but for our custom USB Audio Class device that only works with a certain sample rate. Correct me if I’m wrong, but ASIO4ALL is a user-mode driver (UMDF?) that creates a virtual device to make a bridge between ASIO and an existing WDM driver. This is exactly what I want to do, create an ASIO driver (UMDF if possible for its simplicity) that would create a bridge to the existing USB Audio WDM driver (usbaudio.sys).

The reason why I am looking into developing a custom solution instead of using ASIO4ALL or USB Audio ASIO (www.usb-audio.com), is because our USB Audio Class device supports a specific sample rate and also, as mentioned previously, I would like the driver to allow streaming via UDP/RTP as an extra feature.

I got the ASIO SDK but that is used to communicate with an ASIO driver (what I want to develop). We already got the libraries developed to communicate with ASIO devices.

I hope that clarifies what I’m trying to accomplish. It’s probably way more complicated than what I anticipated but I’d still be willing to do the effort/reading required to accomplish it.

Thanks,
Alex

11

On Apr 22, 2010, at 11:21 AM, xxxxx@gmail.com wrote:

John,

ASIO4ALL is precisely what I’m trying to accomplish but for our custom USB Audio Class device that only works with a certain sample rate. Correct me if I’m wrong, but ASIO4ALL is a user-mode driver (UMDF?) that creates a virtual device to make a bridge between ASIO and an existing WDM driver. This is exactly what I want to do, create an ASIO driver (UMDF if possible for its simplicity) that would create a bridge to the existing USB Audio WDM driver (usbaudio.sys).

You need to be careful with the term UMDF. This isn’t used to refer to user-mode device drivers in general. Rather, it denotes a specific Microsoft Windows technology (the user-mode component of the Window Driver Framework). ASIO4All is not in any way associated with UMDF. It is a standard COM-based dll that employs kernel streaming as a bridge between the ASIO API and standard Windows audio device drivers.

You do not want to use UMDF. What you want is to write a new ASIO dll.

The reason why I am looking into developing a custom solution instead of using ASIO4ALL or USB Audio ASIO (www.usb-audio.com), is because our USB Audio Class device supports a specific sample rate and also, as mentioned previously, I would like the driver to allow streaming via UDP/RTP as an extra feature.

Right. If you look in the driver subdirectory of the ASIOSDK you’ll find sample code for a simple ASIO dll. This is the code you want. What you’ll need to do is add in the support for your ethernet output and for your USB audio driver. If you’re not comfortable with kernel streaming, you might consider starting with one of Microsoft’s other audio APIs instead. You won’t get very good latency from them (unless you go with WASAPI), but they are substantially better documented and should let you get a prototype running. Once you’ve gotten to that point you could look into optimizing it.

I got the ASIO SDK but that is used to communicate with an ASIO driver (what I want to develop). We already got the libraries developed to communicate with ASIO devices.

Actually, it contains both. As I said, look in the driver directory. Everything you need is there.

12

John,

I am aware that UMDF refers to the user-mode part of WDF. What I wasn’t aware is that user-mode device drivers were possible before WDF, that’s why I assumed that UMDF was used for the user-mode driver ASIO4ALL.

So basically, an ASIO user-mode driver (DLL) would act as a layer above Windows kernel streaming, right? I would need to implement the kernel streaming part to the USB Audio device driver (usbaudio.sys). We are currently using WASAPI but the latency obtained in shared mode hovers around 20ms + KMixer, etc. It’s not bad but we can do better with kernel streaming.

The way I see it, UMDF allows to create full-fledged device drivers (i.e. that appear in the Device Manager). The ASIO DLL is basically only a COM DLL that is registered and loaded by applications such as Cakewalk that support ASIO, right? It won’t appear in the Device Manager.

Thanks a lot for the information by the way. It’s very valuable. Let me know if I got it wrong (again). ;p
Alex

13

xxxxx@gmail.com wrote:

I am aware that UMDF refers to the user-mode part of WDF. What I wasn’t aware is that user-mode device drivers were possible before WDF, that’s why I assumed that UMDF was used for the user-mode driver ASIO4ALL.

The word “driver” is overloaded. An ASIO “driver” is just a DLL, like a
TWAIN driver or the Indeo codec driver. It’s not a “driver” in the
Windows sense at all.

So basically, an ASIO user-mode driver (DLL) would act as a layer above Windows kernel streaming, right?

Yes. ASIO is a wrapper DLL around kernel streaming. To the kernel
layer, ASIO is just another application.

The way I see it, UMDF allows to create full-fledged device drivers (i.e. that appear in the Device Manager).

Well, “full-fledged” may be going a bit far ;), but that’s essentially
correct. UMDF only works for those device classes where plumbing can be
used to route requests in user-mode first.

The ASIO DLL is basically only a COM DLL that is registered and loaded by applications such as Cakewalk that support ASIO, right? It won’t appear in the Device Manager.

Exactly correct.

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

14

On Apr 22, 2010, at 1:16 PM, xxxxx@gmail.com wrote:

So basically, an ASIO user-mode driver (DLL) would act as a layer above Windows kernel streaming, right? I would need to implement the kernel streaming part to the USB Audio device driver (usbaudio.sys). We are currently using WASAPI but the latency obtained in shared mode hovers around 20ms + KMixer, etc. It’s not bad but we can do better with kernel streaming.

Actually, the kernel streaming code should reside completely in user mode. The name is a little misleading. It is an API that allows an application to access the kernel streaming mechanisms. I’m concerned that you weren’t getting better latency with WASAPI, though. Were you using it in exclusive mode?

If you find that KS doesn’t get you where you need to be, you’re probably going to need to do some experimenting. If you’re willing to change your kernel mode driver you can bypass much of the Windows audio stack and potentially pick up some performance that way. It may be that your driver itself is the source of the latency, in which case you might need to change the way it is managing the isochronous streams. These kinds of decisions require a detailed understanding the the driver and the underlying device, though, so you’d have to be pretty invested to start down this path.

The way I see it, UMDF allows to create full-fledged device drivers (i.e. that appear in the Device Manager). The ASIO DLL is basically only a COM DLL that is registered and loaded by applications such as Cakewalk that support ASIO, right? It won’t appear in the Device Manager.

Yes, that’s true. The types of drivers that can be created with UMDF are restricted, though. I don’t think it would work well for applications that require consistent low-latency communications, i.e. audio. This is something of an intuitive leap on my part, though. I haven’t ever used UMDF for anything real.