Add multi-stream device support and improve ACX topology, ASIO compatibility, and audio performance

[Akihiro Tokumasu (ymh-akihiro-tokumasu)]

Summary

This Pull Request adds support for USB audio devices that expose multiple Audio Streaming Interfaces, such as the Creative Sound Blaster G3.

To support multi-stream devices, a new Audio Engine has been implemented. As part of this work, the driver's internal class structure, USB Audio Descriptor Parser, stream management, and ACX Circuit generation have been reviewed and reorganized.

Main changes

• Added support for multiple Audio Streaming Interfaces and Clock Sources.
• Reorganized the Audio Engine, internal class structure, and Descriptor Parser.
• Added support for Feature Units and topology controls, including Volume, Mute, and Mixer.
• Improved compatibility with ASIO hosts and DAWs.
• Improved performance and stability when using small buffer sizes.
• Fixed issues identified during development and device validation.
• Added devices validated during development to the INF file.

Known limitations

Devices with multiple independent asynchronous clocks may still have inherent ASIO compatibility limitations, because ASIO may not be able to correctly synchronize all streams across independent clock domains.

Some behavioral differences have also been observed in Feature Unit and ACX topology handling. These may be related to ACX constraints or device behaviors outside the assumptions of the current design. These items will be raised as separate issues after this Pull Request and investigated individually.

Validation

The changes have been tested with multiple USB Audio 2.0 devices and DAWs, including Render, Capture, ASIO, Windows Audio Engine, and multi-stream operation.

Performance with small ASIO buffer sizes has also been confirmed to improve compared with the previous main branch implementation.

Next steps

This Pull Request consolidates the larger changes developed on the multi-streams-support branch.

After this Pull Request, future fixes, commits, validation, and Pull Requests will be handled in smaller and shorter development cycles.

---

Thank you for reviewing this contribution.

[Pete Brown (Psychlist1972)]

Attribution: the findings in this review and in the individual line comments that follow were
produced by GitHub Copilot (Claude Opus 5), reviewing the diff against merge base 2e647f4c
at head 7af4dda. I have read them and agree they are worth acting on, but the analysis and the
line references are the model's. Please push back on anything it got wrong - a couple of items are
explicitly flagged as needing your confirmation.

Thanks for this. I understand why it had to be one change - the object model, descriptor parser, ACX
topology and transfer engine are too interdependent to unpick after the fact, and I am not going to
ask you to split it now. Taking it as it is.

I had Copilot do a focused pass on the defect classes that hurt most in a kernel driver: races,
TOCTOU, lock ordering, use-after-free, teardown lifetime, and error paths that silently report
success. It did not review all 20k lines - see "Not covered" below.

Separately: once this merges I want a thorough review of the whole codebase, not just the diff. That
is a follow-up effort, out of scope here, but it is coming. So if any of the pre-existing items below
feel like they belong to that effort rather than to this PR, that is a reasonable call - say so and
we will track them instead.

Summary

7 defects introduced by this PR. I would like these fixed on this branch before merge. They are
all small, localized changes. Details are in individual line comments.

1. AudioIsochronousEngine::SetAsioBuffer returns STATUS_SUCCESS when the allocation fails
2. Out-of-bounds read in the new Mixer Unit descriptor parser (untrusted USB input)
3. VariableArray::Set leaves the object in a state where the next Set does a null write
4. Engine can be deleted while ACX circuit/pin contexts still hold un-refcounted pointers to it
5. A second EvtDevicePrepareHardware produces a device with no engines and no configuration
6. GetCaptureStreamEngine / GetRenderStreamEngine read state that is written under a lock
7. m_asioBufferOwner is declared but never assigned, so ASIO buffer ownership is not enforced

6 pre-existing issues that this PR moves code around, so it is a natural moment to fix them. I am
not asking for all of these here - happy to take most as tracked issues. But the first two are the
ones I care about:

• user-supplied pointers locked with MmProbeAndLockPages(..., KernelMode, ...)
• TransferObject::CancelRequest can time out and the caller frees the object anyway
• double-fetch of the user-writable ASIO header between validation and use
• unvalidated length - offset subtraction on user input
• capture buffer locked IoReadAccess then written
• assorted: missing null check before KeSetEvent, Out pipe not aborted, ARM64 alignment

What was checked and found sound

Worth saying explicitly, because a lot of this is new and it holds up:

• No ABBA. The three WDFWAITLOCKs are consistently taken in the order Stream -> Asio ->
  StreamEngine on every path examined (D0Exit, StartAsioStream, FileCleanup, StartIsoStream,
  MixingEngineThreadMain, StreamPrepareHardware). Nothing takes them in reverse, and nothing
  takes a wait lock while holding a spin lock.
• MixingEngineThreadMain lock balance is correct. Every break inside a locked region is an
  inner-loop break; the two outer-loop breaks both sit in unlocked windows. This was checked
  statement by statement - it is easy to get wrong and you did not.
• WorkerThread::Terminate is a real join - KeWaitForSingleObject on the thread object with no
  timeout before ObDereferenceObject.
• The outputReadyEvent reference handling in MixingEngineThreadMain is correct -
  ObReferenceObject under the lock, published, then unpublished and dereferenced after Wait().
• UnsetBuffer now releasing both event references is a genuine fix for a pre-existing leak.
• The samplesFirst hoist in CopyToAsioFromInputData fixes a real wrap-around overflow.
• m_numOfInputDevices is assigned only after its array allocation succeeds, so the unguarded array
  index in GetCaptureStreamEngine cannot hit a null array. Still worth annotating, but not a live
  bug.

Not covered

CircuitCommon.cpp (2,596 new lines), most of USBAudioConfiguration.cpp, CaptureCircuit.cpp,
RenderCircuit.cpp, StreamEngine.cpp, InterruptDataMessage.cpp, ContiguousMemory.cpp, and the
user-mode uac2-asio DLL. The descriptor parser in particular wants a dedicated pass with a
malicious-descriptor fuzzer - finding #2 was in the first section of that file that was opened.

Validation ask

Before merge, please run under Driver Verifier with Force IRQL Checking, Pool Tracking and
Low Resources Simulation enabled, plus a surprise-removal-during-ASIO-streaming loop. That
combination targets findings #3 and the two pre-existing lifetime issues directly, and low-resources
simulation is the only practical way to exercise the allocation-failure paths in #1 and #3.

[Pete Brown (Psychlist1972)]

Akihiro Tokumasu (@ymh-akihiro-tokumasu) I've converted the PR to draft. As soon as you have completed the open items, please change it to ready and I'll re-review. Thanks!

Pete
Microsoft