Thanks for the feature request. The internal tracking number is 15417094 if you
call support.
* The current implementation is at least able to parse the UAC descriptors
and to expose more than one input / output to the user
This is correct.
* Couldn't there be a solution based on driver INF files that allow
definition of the device topology published by the driver?
That’s possible but then it’s not a class driver anymore. It’s also possible to
add filter drivers above and below usbaudio2.sys but that is also not a class
driver anymore. The benefit of the proposed improved-channel-routing feature is
that Windows would “just work” with a much larger set of USB Audio 2.0
complaint hardware without custom code.
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx <wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Franz Detro <franz.detro@xxxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, January 11, 2018 1:29:31 AM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: USB Audio Class 2 driver - logical Windows Audio
output devices
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.
This is bad news.
That is to say, it is not a simple matter of updating Windows’ USB audio driver.
Really? It seems that the current implementation is at least able to parse the
UAC descriptors and to expose more than one input / output to the user.
Couldn't there be a solution based on driver INF files that allow definition of
the device topology published by the 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/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblogs.msdn.microsoft.com%2Fmatthew_van_eerde%2F2016%2F09%2F26%2Freport-problems-with-logs-and-suggest-features-with-the-feedback-hub%2F&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C7c73f0f5c65a49e9798608d558d5ef86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636512598233463779&sdata=ECcqshs7qiP%2FVonLqNOhAkoS%2BypA0ILt14aWTnypDSU%3D&reserved=0>
Here is the link:
https://aka.ms/Tq2t0o<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2FTq2t0o&data=02%7C01%7CMatthew.van.Eerde%40microsoft.com%7C7c73f0f5c65a49e9798608d558d5ef86%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636512598233463779&sdata=TIcskipE2Ep3k2GVZXhkNfMnX5AlItSz%2BaZdHUHLqyg%3D&reserved=0>
Can I expedite this through a Support Incident? If yes, could you create /
provide an internal issue number for this?
Regards,
Franz
________________________________
From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
<wdmaudiodev-bounce@xxxxxxxxxxxxx><mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx> on
behalf of Tim Roberts <timr@xxxxxxxxx><mailto:timr@xxxxxxxxx>
Sent: Tuesday, January 9, 2018 10:00:03 AM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto: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.
