[wdmaudiodev] Re: Multi-channel audio USB driver development

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 1 Jul 2010 09:57:25 -0700

A wrapper for what purpose?  I think you're getting tangled in the
terminology here.

DirectKS is a user-mode API that lets applications talk to kernel
streaming drivers without using DirectShow or DirectSound.  An
application that uses DirectKS will be able to talk to any kernel
streaming driver (although it is primarily aimed at audio).  No layers,
no wrappers.  DirectKS **IS** the wrapper.

AVStream is a version of kernel streaming.

> The DDK docs mention that WDMAud.sys performs I/O for the WaveIn / Out
> APIs, so I can use those APIs to send audio directly to the driver kernel?

Only with a very convoluted definition of "directly".  Wdmaud.sys is yet
another layer.  Applications talk to the waveIn/waveOut APIs, which talk
to the user-mode DLL wdmaud.drv, which talks to the kernel driver
wdmaud.sys, which talks to kernel streaming, which eventually gets down
to the kernel streaming driver.  It's certainly not as direct as
DirectKS, and really it's not even as direct as DirectShow.

> However, doesn't this assume that the end user will have ASIO4ALL installed?

The end user doesn't care about this.  What MATTERS is the sophisticated
audio application.  That's what all of this is about.  It's the
APPLICATION that decides how it's going to talk to the audio hardware. 
If the user is doing nothing more than listening to Lady Gaga using
Windows Media Player, then all of this discussion is utterly pointless. 
Media Player uses DirectShow and/or DirectSound.  That API already
exists.  Nothing you do will impact that.

When you talk about providing low-latency audio, you are talking about
providing special services for specific applications.  It is those
applications you need to satisfy.  If those applications are talking to
ASIO, then there has to be an ASIO provider.

> What if I want my hardware to operate independently of ASIO4ALL, then
> I need to write a "wrapper" driver similar to ASIO4ALL, as mentioned above?

This doesn't make sense.  Independently, your hardware is a useless pile
of silicon and gold.  The only way your hardware provides any benefit to
the world is by providing services to audio applications.  Those
applications are already using certain APIs.  Your mission, should you
choose to accept it, is to make sure you support those APIs.

Could you invent your own low-latency API to talk to your hardware? 
Sure you could, but who would use it?  You're never going to convince
mplayer and gstreamer and Audacity and Nero and Cubase all the other
mondo cool applications to expend the effort to write to your API.  And
if you are writing a LAYER to convert ASIO to your ultra-cool API, then
your API is just getting in the way.  Just let ASIO talk to KS.  It can
do that already.

>> USB audio device manufacturers don't write drivers.
> Really? Even in the absence of an ASIO4ALL driver on the users PC?
> What about for pro-audio products, which is what I am developing for?
> For example this company provides their own USB drivers:
> http://www.esi-audio.com/

Their device is not USB Audio Class Compliant.  I don't know whether
they found the class too limiting, or just decided they wanted to go it
on their own.  Yes, they have a full-fledged port class kernel streaming
driver, plus a custom driver that talks to their custom ASIO provider.

>> Up to this point, you have not defined what "low latency" means to you.
> I'm estimating about 20ms.

The standard USB Audio Class driver meets that requirement that without
even breaking a sweat.  Seriously, if that's your requirement, just
forget all of this magic and let the standard system components do what
they are designed to do.  With DirectKS, an application can reduce the
latency to 4ms, still using nothing but standard system components.

> Could you recommend the most sensible way to approach writing for multiple OS,
> namely Win2K, XP, Vista, 7? I would like to re-use as much code as possible.
> Do you think 6 months is a reasonable estimate for development time?

I still don't think you need to write a driver at all.

A single AVStream driver will work just fine in all of the systems you
mention.  In fact, it will even work in Windows 98, if you install
DirectX 8.

If you do stubbornly decide you need to write a driver, 6 months is a
reasonable estimate, but I suspect you're wasting your time.

Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.


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: