[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
streams.
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:
