[wdmaudiodev] Re: UAA Driver Information
- From: Hakon Strande <hakons@xxxxxxxxxxxxxxxxxxxxx>
- To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Thu, 6 Dec 2007 09:54:29 -0800
That depends on what these additional features are. In any case class driver
compliance for base level functionality as outlined in the Windows logo
requirements and in our design guidelines is a noble goal that will in the end
help users of your hardware in situations where your driver is not available or
not working (rollbacks, clean installs, OS upgrades in the future, etc).
The class driver's role is not to replace 3rd party drivers but rather to
minimize user frustration when the 3rd party driver is not available. This
happens more often than most of us realize.
We should take this off line and get an NDA in place so you can tell me more
about these additional features - most audio processing value-add can be
implemented on top of class drivers in the System Effect infrastructure (Vista
and future OS only).
Email me directly if you want to discuss further.
Sincerely,
Hakon Strande | Windows Sound Team PM | (p) 425.705.0637
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Pev
Sent: Thursday, December 06, 2007 8:24 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: UAA Driver Information
Ah Hakon, hi!
I just recognised your name as the author of the WinHEC presentation I
was referring to earlier!
> Why don't you just build a class driver compliant device and save
> yourself all the troubles of developing your own driver?
So, to summarise - I'm needing to develop a driver for a new HDA codec
that whilst largely conformant to the HD Audio specification adds
additional functionality not covered by the HD Audio specification via
new vendor specific verbs. So as I read the documentation that's
available (thanks for the links Brad but I'd already thoroughly read
those!) it appears that I'm not going to be able to be able to hook
into the class driver in any way to extend it to utilise the
functionality.
For example, in the "Universal Audio Architecture" overview document
(UAA_Overview.doc) it states :
Reduced Need for Vendor-Supplied Drivers Scenario
A vendor implements a UAA audio design with features supported by the
UAA class driver. The vendor does not need to ship an additional
driver to make the device work.
The same vendor develops a UAA-compliant audio device that provides
some advanced audio features that are not supported by the UAA class
driver. The vendor writes a driver that enables the advanced features
of the device. The user can install the vendor's driver to enable all
of the capabilities of the hardware, or the user can rely on the UAA
class driver for basic audio features.
So initially for sure we want to adapt the class driver for use with
the hardware to validate the design - it sounds like we'd need the
'IHV kit' you mention to assist this?
However, after this when we want to be able to adapt to utilise the
additional features the way I read this is that we would have to write
a completely new driver or am I misunderstanding this?
Best Wishes,
~Pev
******************
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
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
******************
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
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
Other related posts:
