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.