ASIO driver use-after-free when a device fails the capability check

[ann0see]

Summary

Use-after-free on the ASIO SDK's global theAsioDriver pointer when a device
fails the capability check. On current main, a device that fails
CheckDeviceCapabilities() during ASIO re-init can leave a dangling global
pointer that a later re-init dereferences. Symptoms are inconsistent — hang,
crash, or silent corruption — which matches the reports in #872 and #305.

Context

• Jamulus process doesn't get killed if you select a device with wrong sample rate (ASIO4ALL) #872 (closed 2021) reported the "process doesn't get killed / ASIO4ALL red
  cross lockout" symptom; the root cause was not identified then.
• Discovered as part of the Investigate Windows Hang if using ASIO4ALL especially #3779 investigation (Windows hang with ASIO4ALL),
  in which Jamulus process doesn't get killed if you select a device with wrong sample rate (ASIO4ALL) #872's defect is one of several distinct problems.

Evidence (mcfnord, on Windows — issue #3779 comment 5224437188)

One honest caveat up front: this measurement was done with a synthetic test
driver that deliberately fails the capability check, not with ASIO4ALL on real
hardware. With that said:

• This is a use-after-free, not a leak: ASIOExit() is effectively
  removeCurrentDriver() + theAsioDriver = 0. The current failure branch
  only does the first of those.
• Outcome is driver-dependent: ASIO4ALL's driver object is static in its
  DLL and survives the COM release (→ hang / lockout); Focusrite USB
  ASIO's object is heap-allocated, so the next call faults (0xC0000005).
• With the synthetic driver, the stock build (4d142945) made seven ASIO
  calls on the freed object; with ASIOExit(), zero.

How to reproduce

The reliable repro we have is with a synthetic driver that fails
CheckDeviceCapabilities() on demand. On real Windows hardware with ASIO4ALL
this is our best guess at hitting the same path — it is unverified:

1. Select a device that fails the capability check (e.g. one that does not
   support the required sample rate) while a valid device is also available.
2. Trigger re-init (e.g. change the audio device in the client settings).
3. Re-select the previous working device.

The failure branch is hit at CSound::LoadAndInitializeDriver()
(src/sound/asio/sound.cpp) — CheckDeviceCapabilities() fails, the driver is
released via asioDrivers->removeCurrentDriver(), and the global
theAsioDriver pointer is left dangling. A subsequent re-init dereferences it.

Proposed fix

In CSound::LoadAndInitializeDriver() (src/sound/asio/sound.cpp), the
CheckDeviceCapabilities() failure branch should call ASIOExit() instead
of asioDrivers->removeCurrentDriver(), so the global pointer is nulled. The
ASIOInit()-failed branch is left alone — from reading the ASIO SDK it resets
the global pointer on that path, though I haven't instrumented it to be sure.

A ready patch exists in fork PR ann0see/jamulus#286 (one-line change + comment),
reproducing the 7-vs-0 result. This issue is opened to track the defect so the
fix is not lost if the fork PR is never reopened upstream.

Requested actions

• Review whether the failure branch should use ASIOExit().
• If agreed, apply the fix on main (a small, low-risk change).

⚠️ AI-generated issue — please verify

• This text is AI generated, may be wrong, and may contain inaccuracies.
• The hardware verification described below was performed by a human with an AI agent
  (mcfnord, on Windows).

[ann0see]

Opened to track the capability check potential bug.

[ann0see]

⚠️ AI-generated — may not be correct. Please verify before acting.

Very brief diff idea (for the fix in this issue)

In CSound::LoadAndInitializeDriver() (src/sound/asio/sound.cpp), the
CheckDeviceCapabilities() failure branch:

-        // driver cannot be used, clean up
-        asioDrivers->removeCurrentDriver();
+        // driver cannot be used, clean up with ASIOExit() (also nulls theAsioDriver)
+        ASIOExit();

The idea is that ASIOExit() closes the session and nulls the SDK global
theAsioDriver, preventing the use-after-free. This is just an idea and may
not be correct — e.g. the exact return/error path may differ on current
main, or ASIOExit() may have side effects the branch should avoid.