[wdmaudiodev] Re: Streaming SPEEX encoded voice over USB Audio class 1.0

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Fri, 22 Jan 2010 09:37:03 -0800

Szabolcs Sandoly wrote:
> I have already found this citation in the mentioned documents, but I
> have not found the way how to configure the format descriptors for
> exploit the “vendor specific format” yet.
> This document says nothing about it.

I believe you would just use a type code that's not in the document.

> I have something in my mind to solve this. What happens if, I add new
> format code OR use the TYPE_II_UNDEFINED code at the Audio Data Format
> Type II Codes, which will declare the SPEEX codec.
> The filter driver will sit on top of the usbaudio.sys and identify the
> stream as SPEEX and routes it to the proper audio codec in the system.
> Does this sounds reasonable?

Mostly, but the key unanswered question (for me) is whether usbaudio.sys
will handle a datastream of type TYPE_II_UNDEFINED.  It might simply
refuse to create the device.  Remember that it is the job of
usbaudio.sys to take your descriptors and convert them into kernel
streaming KSDATAFORMAT structures.  If it can't map the type code into a
KSDATAFORMAT major/minor type, I suspect it will throw up its hands in
disgust.  Video Class has a well-defined method for exposing vendor
formats, but Audio Class does not.

Because of that, you might have to report some valid type code, then
have your upper filter rewrite the data format IRPs.  That's a problem,
because it means your device will work incorrectly without any notice on
a system where your driver is not installed.

The other alternative is to write your own audio driver from the bottom up.

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

Other related posts: