Franz, if you would like such a device to work with Windows, there would need
to be a new feature added to Windows to more intelligently route audio channels.
That is to say, it is not a simple matter of updating Windows’ USB audio driver.
You can submit a feature suggestion for such a feature via Feedback Hub – see
https://blogs.msdn.microsoft.com/matthew_van_eerde/2016/09/26/report-problems-with-logs-and-suggest-features-with-the-feedback-hub/
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Tim Roberts <timr@xxxxxxxxx>
Sent: Tuesday, January 9, 2018 10:00:03 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: USB Audio Class 2 driver - logical Windows Audio
output devices
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? 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.
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. 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.
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.