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
Providenza & Boekelheide, Inc.
