[BUG]: Multi-stream UAC2 endpoints have indistinguishable names

[nickknyc]

Windows Version

Windows 11 Pro, version 2009, build 26200 (10.0.26200.0 observed previously in PowerShell transcript).

PC Information

Gigabyte Technology Co., Ltd. Z590I VISION D, x64-based PC.

Processor Architecture

x64 (AMD / Intel etc.)

Audio Interface

TASCAM Model 12

Audio function:

USB\VID_0644&PID_805F&MI_00\7&faa69ba&0&0000

Local INF entry used for this test:

We did not create a separate INF from scratch. In the local Studio13 fork, we modified the existing driver INF and added this exact entry:

%USBAudio2-ACX.DeviceDesc%=USBAudio2-ACX_Device, USB\VID_0644&PID_805F&MI_00  ; Tascam Model 12

That entry targets only the Model 12 USB audio interface (MI_00). The Model 12 MIDI interface is separate (MI_03) and remained on the normal Windows USB MIDI path (usbaudio / wdma_usb.inf).

Current local driver state:

Service: USBAudio2-ACX
Driver package: oem154.inf
DriverVersion: 07/22/2026 14.55.18.295
Kernel service: Running
DriverStore path: C:\WINDOWS\system32\DriverStore\FileRepository\usbaudio2-acx.inf_amd64_b1be05e511ba163e\USBAudio2-ACX.sys

Audio Interface Connection

Unknown or unsure.

Sample Rate

Not sample-rate-specific. Observed during endpoint enumeration. Current test setup is generally using 48 kHz.

Buffer Size

N/A for this endpoint naming issue.

Application in use

Windows Settings > Sound; Roon audio setup.

Audio Mode

Windows Audio (WASAPI etc.)

Type of bug

Other: endpoint naming / multi-stream endpoint UX.

Steps to reproduce

1. Build/install the current multi-streams-support USBAudio2-ACX driver locally and bind a multi-output UAC2 device. In this case the device is a TASCAM Model 12, USB\VID_0644&PID_805F&MI_00.
2. Open Windows Settings > Sound output device list, or Roon Settings > Audio.
3. Observe the render endpoints exposed by the driver.

Actual user-visible result:

Speakers (USBAudio2-ACX)
Speakers (USBAudio2-ACX)
Speakers (USBAudio2-ACX)
Speakers (USBAudio2-ACX)
Speakers (USBAudio2-ACX)

Roon similarly shows multiple indistinguishable USBAudio2-ACX WASAPI entries. The user cannot tell which endpoint maps to which Model 12 USB output pair.

Expected behavior

Each endpoint should have a stable, distinguishable display name that includes direction and channel pair/range. For example, a useful fallback for this device would be:

Model 12 Out 1/2
Model 12 Out 3/4
Model 12 Out 5/6
Model 12 Out 7/8
Model 12 Out 9/10
Model 12 In 1/2
...
Model 12 In 11/12

The exact naming convention is less important than making the endpoints distinguishable in Windows Settings and WASAPI clients.

Additional notes

This issue is only about endpoint display names.

Relevant source observations from this repo:

src\uac2-driver\AudioIsochronousEngine.cpp:327-367

AudioIsochronousEngine already tries to build a per-stream AudioProperty.ProductName from USB terminal names. If terminal names are not available, it falls back to broad names such as ProductName Input N, ProductName Output N, or ProductName N.

src\uac2-driver\AudioIsochronousEngine.cpp:607-653

The ASIO channel map also tries to read USB channel names and falls back to the audio property product name.

src\uac2-driver\CircuitCommon.cpp:1556-1565
src\uac2-driver\CircuitCommon.cpp:1842-1851

There are comments noting that when the category is KSNODETYPE_SPEAKER, the name retrieved by EvtAcxPinRetrieveName is not used and Windows displays Speaker. The current workaround changes the category to KSNODETYPE_LINE_CONNECTOR only when a valid channelNames descriptor is present.

src\uac2-driver\USBAudio2-ACX.inf:101-120

The INF sets static friendly names for render/capture interface registrations and endpoint properties for association and event-driven mode. It does not appear to provide per-dynamically-created endpoint names for each output pair.

Question: can the ACX endpoint creation/property path expose stable per-endpoint display names derived from stream direction and channel range even when the USB device does not provide useful channel-name string descriptors? If ProductName / EvtAcxPinRetrieveName is not the right mechanism, which endpoint property should this driver set so Windows Settings, WASAPI clients, and Roon show disambiguated names?

I can provide screenshots and the local Switch-USBAudio2ACX.ps1 -StatusOnly output if useful.

[nickknyc]

Clarification on how the Model 12 was matched for this local test:

We did not create a separate INF from scratch. In the local Studio13 fork, we modified the existing driver INF to add the Model 12 audio-interface hardware ID:

%USBAudio2-ACX.DeviceDesc%=USBAudio2-ACX_Device, USB\VID_0644&PID_805F&MI_00  ; Tascam Model 12

Local source path:

src\uac2-driver\USBAudio2-ACX.inf

That modified INF was built, staged, test-signed, and installed locally. Windows published the installed package as:

oem154.inf
DriverVersion: 07/22/2026 14.55.18.295
Service: USBAudio2-ACX

Scope note: this INF entry targets only the Model 12 USB audio function:

USB\VID_0644&PID_805F&MI_00

The Model 12 MIDI function is a separate USB interface and remained on the normal Windows USB MIDI path:

USB\VID_0644&PID_805F&MI_03
Service: usbaudio
Driver: wdma_usb.inf

So the endpoint naming issue here is specifically about the ACX audio endpoints created after binding the Model 12 audio interface (MI_00) to the modified USBAudio2-ACX.inf package.

[ymh-akihiro-tokumasu]

Thank you for the detailed report and analysis.

I have addressed this issue and pushed the fix in the following commit:

Fix: Use predefined channel names when String Descriptors are unavailable on split-channel devices (Addresses #29)

7ecd1cc

For devices where channel names cannot be retrieved from the USB descriptors, multiple split endpoints were previously enumerated with indistinguishable names such as Speakers (USBAudio2-ACX). With this fix, the Speakers part will be replaced with a name based on the input/output direction and channel range.

The (USBAudio2-ACX) part is expected to become the actual device name in the future, so I did not include ProductName in the string returned by EvtAcxPinRetrieveName.

A Pull Request to main has not been created yet. I will follow up on that separately.

Please review it when you have a chance.
Thank you.

[nickknyc]

Thank you. I reviewed 7ecd1cc, and it addresses the Windows/WASAPI endpoint problem reported in this issue: when USB channel-name String Descriptors are unavailable, the ACX pin callbacks now return direction/channel-range names instead of leaving several endpoints displayed as Speakers (USBAudio2-ACX).

During follow-up validation with the TASCAM Model 12, we found a related but separate naming problem in the ASIO path. AudioIsochronousEngine::BuildChannelMap() still falls back to AudioProperty.ProductName when per-channel descriptor lookup fails. That causes all ASIO channels to carry the same name (Model 12 in this case), and IASIO::getChannelInfo() previously returned those duplicate names unchanged. Reason therefore displayed twelve indistinguishable ASIO inputs even though the ACX/WASAPI endpoint-name fix was conceptually correct.

We addressed that separate ASIO behavior in #41, targeting main:

#41

The ASIO change:

• preserves nonempty, unique USB descriptor names;
• falls back to Input N or Output N when names are empty or duplicated within that direction;
• changes only src/uac2-asio and its tests, with no kernel streaming or ACX endpoint changes.

Runtime validation on Windows 11 Pro with the Model 12 reported 12 distinct inputs and 10 distinct outputs at 48 kHz / 512 samples. Reason displayed the numbered mono inputs and derived stereo pairs such as Input 1 + Input 2; 44.1 kHz and 48 kHz imported audio then played separately and together without dropouts.

So 7ecd1cc remains the appropriate fix for this issue's ACX/WASAPI endpoint names. PR #41 is its ASIO-side complement, not a replacement.