[wdmaudiodev] Re: USB Audio Class 2.0

  • From: Børge Strand-Bergesen <borge.strand@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Fri, 28 Mar 2014 10:04:20 +0100

Hi Dominik,

You have my full support with everything you say here!

Towards a realistic driver development effort I pledge USD500 and 10 USB
DACs capable of both UAC1 and UAC2. (See
http://www.henryaudio.com/uploads/fact_sheet.pdf for details)

Good sounding MS drivers will lead to hi-end and pro products, will lead to
early adopters, will lead to consumer adoption. That's the chain of cause
and effect, not the other way around.

I know a few serious audio users. They buy dedicated computers for audio
playback. 90% of those are Macs. In fact, those Macs are almost all that
particular user's very first Mac.

Frank, if you need to convince your colleagues about this, let us know and
we can help you.


Børge



On Fri, Mar 28, 2014 at 2:26 AM, Dominik Peklo
<dominikp@xxxxxxxxxxxxxxxxx>wrote:

>
> Dear Frank,
>
> The question should really be "Why NOT have a native UAC2 support?" It's
> mind boggling actually that one of the major USB classes is completely
> ignored by Microsoft for so many years. The lack of Windows native support
> has far reaching consequences in consumer and pro-audio industries. OS
> always has to be a step ahead of the market adoption for Plug'n'Play
> concept to work! It's chicken & egg problem really. Most smaller Hi-Fi
> companies would pass on HS USB interfaces due to not having the resources
> to build and maintain their own drivers. The few brave ones reluctantly do
> so out of desperation. Pro audio companies would immediately benefit from
> extended channel count in both directions, proper clock source management,
> physical controls associations etc., but will only license
> solutions/drivers from a few cottage industry players for their higher-end
> products as they cannot afford to do so across the range. UAC2 controller
> silicon is not being designed due to missing native driver support. Third
> party driver quality/stability is always cited as the most common reason of
> OS crashes and Microsoft should try hard to eliminate any need for them on
> principle alone! Many exotic devices can be easily handled by user-mode
> drivers, but unfortunately WDM streaming driver is not one of them.
> Microsoft really became the greatest inhibitor of a growth in computer
> audio in general and it ain't getting any street cred for that. Hell even
> iPad does UAC2 out the box!
>
> How about this - if you find it hard to justify the development resources
> required, just go and ask every single player in the audio industry for a
> small financial contribution in exchange for delivering and maintaining
> native UAC2 support for NT6+ and I guarantee you will raise plenty enough
> to make it happen. Instead of paying 3rd parties, they'd happily pay
> Microsoft instead and make the driver issue disappear for their customers.
> Nobody wants to do their own drivers. No user wants to install device
> drivers in this day and age. How about a Kickstarter campaign?
>
> Sincerely,
> Dominik Peklo
>
>
> On Tue, Mar 25, 2014 at 3:55 PM, Børge Strand-Bergesen <
> borge.strand@xxxxxxxxx> wrote:
>
>> My impression is that a practical UAC2 device is one that works on OS X.
>> With OS X support in place, tweak it to work wil Linux, after that write a
>> Windows driver which emulates the other two.
>>
>> I have seen parts of the descriptor interpreted very differently on
>> different OSes. There might be a bug in the firmware I'm using, or it may
>> be the different OSes interpret it differently. The above method at least
>> rendered a working device.
>>
>> Børge
>>
>>
>>
>> On Mon, Mar 24, 2014 at 6:37 PM, Geert Knapen 
>> <geert@xxxxxxxxxxxxxxxxxxx>wrote:
>>
>>> Hi Jerry,
>>>
>>> The example document was never finished (not even really started :-().
>>> So I am afraid that nothing is available and the Audio working group is not
>>> active at this time...
>>>
>>> Kindest Regards,
>>>
>>>   [image: D&A] <http://www.designandadvice.com> [image: JW House]
>>> <http://www.jwhouse.org> *Geert Knapen*
>>> President/Owner
>>>
>>>
>>> *Design & Advice, L.L.C.* <http://www.designandadvice.com>
>>> 1725 Martin Avenue, San Jose CA 95128
>>> e-mail: geert@xxxxxxxxxxxxxxxxxxx | Tel: +1-408-297-3731 | Cell:
>>> +1-408-507-7852 | Google Voice: +1-408-805-4320
>>>
>>> On Mar 23, 2014, at 12:26 PM, Jerry Evans <jerry@xxxxxxxxxxx> wrote:
>>>
>>> Hello Geert
>>>
>>> I wonder if you might be able to help with a more general AC2 issue. In
>>> the list of 'Key Differences', the Release 2.0 'device class definition for
>>> Audio Devices' document states that 'split off the examples in a separate
>>> document'. Did any such document ever get published? Is there a draft
>>> available perhaps? Given the (sad) paucity of AC2 compliant devices such a
>>> document would be extremely helpful for implementors ...
>>>
>>> Many thanks
>>>
>>> Jerry
>>>
>>> *From:* wdmaudiodev-bounce@xxxxxxxxxxxxx [
>>> mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx<wdmaudiodev-bounce@xxxxxxxxxxxxx>
>>> ] *On Behalf Of *Geert Knapen
>>> *Sent:* 14 February 2014 23:09
>>> *To:* wdmaudiodev@xxxxxxxxxxxxx
>>> *Subject:* [wdmaudiodev] Re: USB Audio Class 2.0
>>>
>>> May I suggest to have a look at Section 2.1 in the Audio 2.0 spec:
>>>
>>> *2.1 Overview of Key Differences between ADC v1.0 and v2.0*
>>>
>>> The following list is not an exhaustive list of all changes that have
>>> been introduced. For complete information, refer to the full specification.
>>> Pay special attention to Sections 1 through 6!
>>>
>>> ·         Complete support for high speed operation - no longer are
>>> audio class devices limited to full speed operation.
>>>
>>> ·         The notion of physical and logical Audio channel clusters.
>>>
>>> ·         The number of predefined spatial locations has increased. In
>>> addition, a virtual spatial location
>>>
>>> called Raw Data was introduced.
>>>
>>> ·         Use of the interface association descriptor - The standard
>>> Interface Association mechanism is used
>>>
>>> to describe an Audio Interface Collection. The former class specific
>>> mechanism was deprecated.
>>>
>>> ·         Descriptor updates: fixed offsets associated with many
>>> descriptors and enlarged three byte fields
>>>
>>> into four bytes.
>>>
>>> ·         Extensive support for interrupts to inform the host about
>>> dynamic changes that occur on the
>>>
>>> different addressable Entities (Clock Entities, Terminals, Units,
>>> interfaces and endpoints) inside
>>>
>>> the audio function.
>>>
>>> ·         More clarification text on the audio function.
>>>
>>> ·         Audio Control Changes.
>>>
>>> o    -  Control attribute changes.
>>>
>>> o    -  Mixer Unit control request (set/get pairs changed).
>>>
>>> o    -  Many updates in the control descriptions.
>>>
>>> ·         Added support for clock domains, clock description and clock
>>> control.
>>>
>>> ·         Added additional Audio Controls inside a Feature Unit (Input,
>>> Gain, Input Gain Pad ...)
>>>
>>> ·         Added bit pairs in descriptors to indicate presence and
>>> programmability of every Control
>>>
>>> ·         Prohibited the use of Alternate Setting switching to change
>>> sampling frequencies. Instead, Clock
>>>
>>> Entities are introduced that can be manipulated (through the
>>> AudioControl interface) to select
>>>
>>> operating sampling frequencies.
>>>
>>> ·         Split off the examples in a separate document.
>>>
>>> ·         Allowed binding between physical buttons on the audio
>>> function and the corresponding Audio
>>>
>>> Control. Prescribed how this is done.
>>>
>>> ·         Added an Effect Unit to group algorithms that work on logical
>>> channels separately but require
>>>
>>> multiple parameters to manipulate the effect (as opposed to basic
>>> (single parameter) manipulation,
>>>
>>> performed in a Feature Unit).
>>>
>>> ·         Introduced Parametric Equalizer Section Effect Unit.
>>>
>>> ·         Rearranged Reverb, Modulation Delay and Dynamic Compressor
>>> PUs under the new Effect Unit.
>>>
>>> ·         Added the concept of audio function Category. The Category
>>> indicates the primary use of the
>>>
>>> audio function as envisioned by the manufacturer.
>>>
>>> ·         Added the Sampling Rate Converter Unit.
>>>
>>> ·         Added a means to express Latency of individual building
>>> blocks within the audio function.
>>>
>>> ·         Added Encoder support.
>>> Of course, these are all technical differences and do not necessarily
>>> directly translate in specific reasons to invest in Audio 2.0 :-)
>>>
>>> Kindest Regards,
>>>
>>> Geert Knapen
>>>
>>> USB Audio DWG Chair
>>> <~WRD000.jpg> 
>>> <http://www.designandadvice.com/><~WRD000.jpg><http://www.jwhouse.org/>*Geert
>>> Knapen*
>>>
>>>
>>>
>>> *Design & Advice, L.L.C.* <http://www.designandadvice.com/>
>>> 1725 Martin Avenue, San Jose CA 95128
>>> e-mail: geert@xxxxxxxxxxxxxxxxxxx | Tel: +1-408-297-3731 | Cell:
>>> +1-408-507-7852 | Google Voice: +1-408-805-4320
>>>
>>> On Feb 14, 2014, at 2:45 PM, Matthew van Eerde <
>>> Matthew.van.Eerde@xxxxxxxxxxxxx> wrote:
>>>
>>>
>>>  Specific reasons to invest in USB Audio 2.0:
>>>
>>> * Higher bit rate enables more formats
>>> * Dynamic jack presence detection
>>> * Anything else?
>>>
>>> -----Original Message-----
>>> From: wdmaudiodev-bounce@xxxxxxxxxxxxx [
>>> mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx<wdmaudiodev-bounce@xxxxxxxxxxxxx>]
>>> On Behalf Of Børge Strand-Bergesen
>>> Sent: Friday, February 14, 2014 2:38 PM
>>> To: wdmaudiodev@xxxxxxxxxxxxx
>>> Subject: [wdmaudiodev] Re: USB Audio Class 2.0
>>>
>>> Thank you Phil.
>>>
>>> The market demands Hi-Res, science of not.
>>>
>>> Microsoft will sell more OS licenses with UAC2 support. Apple will
>>> sell less Macs with Windows UAC2 support. Enough to justify the
>>> investment? I think yes. Enough to get a measurable peak on the first
>>> quarterly report? Probably not.
>>>
>>>
>>> Børge
>>>
>>> P.S. I'm sorry for going OT with the mention of megapixels and MHz.
>>> I'm just trying to see the world of electroncis through the eyes of
>>> the people browsing the shelves at Best Buy. Having a number to
>>> compare will tip their scale. Lots of users will ignore the not easily
>>> quantifiable quality of the optics if the other camera has more
>>> pixels. Currently, UAC2 DACs don't play out of the box, and they sell
>>> to customers who care about the quality of the optics. Make them play
>>> out of the box and they will sell to the much larger crowd which
>>> doesn't.
>>>
>>> P.P.S Don't forget the placebo effect. This DAC has more X than that
>>> other one, so it _must_ sound better. No UAC2, no cake!
>>>
>>>
>>> On Fri, Feb 14, 2014 at 7:42 PM, Philip Gruebele <pgruebele@xxxxxxx>
>>> wrote:
>>>
>>>  Three points worth making:
>>>
>>> 1. Whether or not it is technically necessary to support higher sample
>>> rates
>>> is not relevant.  What is relevant is whether the market demands it, and
>>> it
>>> undeniably does.  Otherwise why would so many companies - hardware
>>> manufacturers and download services - invest so many resources to make it
>>> happen?
>>>
>>> 2. Using Nyquist and human hearing to make a case for not supporting
>>> higher
>>> sample rates is looking at the issue too narrowly.  The reason higher
>>> sample
>>> rates can be better are complex and include things like simplifying DAC
>>> design and out-of-band filtering. Also some protocols like DSD64 over DoP
>>> require 176.4Khz and DSD128 requires double that just to get the data
>>> across.  UA2.0 also supports certain use cases which are not possible
>>> with
>>> UA1.0.  The minimum sample rate that should be supported is at least
>>> 384Khz
>>> and UA2.0 has handled all these cases for many years.
>>>
>>> 3. The lack of USB Audio 2.0 support causes a headache for consumers
>>> because
>>> they have to deal with low quality, poorly test, third party drivers.
>>>  These
>>> drivers are not going away because of point (1). There are a LOT of
>>> high-end
>>> audio enthusiasts who voted against Windows by using Apple products
>>> because
>>> they provide a better end-user experience.
>>>
>>> -phil
>>>
>>> Tim Roberts wrote:
>>>
>>>
>>> Børge Strand-Bergesen wrote:
>>>
>>>
>>> I'm sorry Tim, but this is like saying Canon & Co. should have stopped
>>> adding megapixels once their cameras got 4 or so of them.
>>>
>>> No, this is not a valid comparison.  Our eyes can tell the difference
>>>
>>> between 300dpi and 600dpi, and a 4MP camera can only do about 200dpi
>>> when printed at 8.5x11.  Those extra pixels ARE being put to use.
>>>
>>> The same is simply not true of audio.  You don't "zoom in" on an audio
>>> track.  The concept doesn't make sense.  The best human ears are
>>> physically unable to sense frequencies above about 20kHz.  Per Nyquist,
>>> anything above twice that frequency serves no purpose at all.  They
>>> CANNOT, physically, alter what we sense in the sound.
>>>
>>> It reminds me of the "Dominator DMX 10" scene from Ruthless People:
>>>     http://www.youtube.com/watch?v=mNzr6lfiHJE
>>> (Caution: language)
>>>
>>>
>>>
>>>  kHz is a simple number. Comparing the kHz of your audio system will be
>>> done in the consumer crowds just like they compared the MHz of their
>>> CPUs and the megapixels of their cameras. The more you have of that
>>> simple metric, the better they will feel.
>>>
>>>
>>> That's voodoo, not engineering.  Those MHz and megapixels are being
>>>
>>> used.  Those extra kHz are utterly pointless.  Unlike the other two, we
>>> have reached a physical limit.
>>>
>>>
>>> ******************
>>>
>>> WDMAUDIODEV addresses:
>>> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx<wdmaudiodev@xxxxxxxxxxxxx>
>>> Subscribe:    
>>> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe<wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe>
>>> Unsubscribe:
>>> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe<wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe>
>>> Moderator:    
>>> mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx<wdmaudiodev-moderators@xxxxxxxxxxxxx>
>>>
>>> URL to WDMAUDIODEV page:
>>> http://www.wdmaudiodev.com/
>>>
>>> ******************
>>>
>>> WDMAUDIODEV addresses:
>>> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx<wdmaudiodev@xxxxxxxxxxxxx>
>>> Subscribe:    
>>> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe<wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe>
>>> Unsubscribe:
>>> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe<wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe>
>>> Moderator:    
>>> mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx<wdmaudiodev-moderators@xxxxxxxxxxxxx>
>>>
>>> URL to WDMAUDIODEV page:
>>> http://www.wdmaudiodev.com/
>>>
>>> ******************
>>>
>>> WDMAUDIODEV addresses:
>>> Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx<wdmaudiodev@xxxxxxxxxxxxx>
>>> Subscribe:    
>>> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe<wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe>
>>> Unsubscribe:
>>> mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe<wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe>
>>> Moderator:    
>>> mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx<wdmaudiodev-moderators@xxxxxxxxxxxxx>
>>>
>>> URL to WDMAUDIODEV page:
>>> http://www.wdmaudiodev.com/
>>>
>>>
>>>
>>
>

Other related posts: