[wdmaudiodev] Re: USB Audio Class 2 driver - logical Windows Audio output devices

  • From: Franz Detro <franz.detro@xxxxxxxxxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Thu, 11 Jan 2018 09:36:55 +0100

Franz Detro wrote:

A more reasonable layout would be

                                           +- Mixer Unit (4 in / 2 out) - 
External Terminal (Line Connector)
USB Streaming Input Terminal (4 channels) -+ 
                                           +- Mixer Unit (4 in / 2 Out) - 
Output Terminal (Type Headphones)

with the mixer extracting the matching channels (1/2 or 3/4) for the Line 
Output and Headphone Output. 

Why is this more reasonable?  How is an outside observer supposed to know 
about this mapping?

A driver could query this mapping from the UAC descriptor and through UAC 
requests on the mixer terminals.

I totally understand that this is not really straight forward, unfortunately 
UAC2 does not provide means to model extraction of individual busses from a USB 
data stream. UAC3 does provide some means to better document the content of a 
stream structure, but unfortunately also no terminals for splitting such 

  Why could it not be the other way around?  It doesn't seem natural to me at 
all that the "line out" and "headphone out" signals ought to be coming 
through the same streaming input, although the architecture certainly doesn't 
forbid it.

Splitting these signals into different streams / interfaces / endpoints would 
complicate things drastically on the firmware, driver and application side. 
Internally the device is a multi-channel device with several physical outputs 
(line, headphone) and one common clock.

The most common use case for such a device is a host software (e.g. a DJ 
application) that sends audio to the main out (club PA) and headphone (Cue / 
Prehear) simultaneously.

Experiments using this layout are successful regarding appearance of the 
output devices in the system, but not regarding the right signals being sent 
to the right logical output (it seems that the driver always only uses the 
first two USB streaming channels with both output devices).

It has to make some choice, and since it has no way to know what you actually 
want, this arbitrary choice is as good as any.

Sure. As mentioned these were only experiments against the current 
implementation of the UAC2 driver.

  In this case, it is clearly up to the application (which understands the 
topology) to go configure the mixers to produce the desired result.  The 
audio subsystem cannot guess the right answer here.

I agree for the application case (this indeed works fine), but not for the 
audio system. Other operating systems like MacOS, iOS and Linux do expose the 
channel names published by the device to the user, and provide means that allow 
the user to select the channels to be used.

Unfortunately Windows Audio does not have the concept of a channel name, and 
the UAC(2) driver assumes that a USB stream only consists of a single bus (with 
four channels in our case).

What we need for such devices is a mechanism to advertise the busses to the 
user, similar to what we have for internal devices providing headphone, 
speaker, HDMI etc. outputs.

Is this a bug in the Audio Class driver? If not, what is the recommended way 
to model such common cases? Is it possible to provide a device specific INF 
file describing the device topology?

I think you have fallen into the trap of believing that your unique situation 
is a common situation.
Tim Roberts, timr@xxxxxxxxx <mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.

Other related posts: