Add optional PyTorch/CUDA acceleration for Stable Audio 3 on Windows

[brxs]

Summary

Add optional PyTorch/CUDA acceleration for Stable Audio 3 on Windows while retaining the TFLite backend as the supported CPU fallback. This enhancement must not block the initial Windows release.

Dependencies and release relationship

• Refactor LSDJ's cross-platform application foundation #107
• Add a production PyTorch MRT2 backend for Linux and Windows #110
• Add a portable Stable Audio 3 TFLite backend #111 provides the required fallback and parity contract.
• Add third-party model licensing, attribution, and download acknowledgement #108 owns user-facing terms, attribution, and acknowledgement.
• This is a non-blocking follow-up to Ship Windows 11 x64 + NVIDIA support #113.

Architecture constraints

• Consume the upstream stable-audio-3 implementation as a pinned external dependency. Do not create or maintain an LSDJ fork.
• Reuse the production MRT2 PyTorch/CUDA runtime pack only if the pinned dependency sets can be resolved, packaged, upgraded, and tested as one coherent environment.
• A single shared runtime is a qualification gate, not an assumption. If dependency resolution fails, report the blocker and revisit scope; do not silently ship two separate multi-gigabyte PyTorch environments.
• Keep TFLite installed/available as the reliable fallback.
• Run GPU Stable Audio in an on-demand child worker so cancellation or exit can release VRAM reliably.

Scope

API and feature mapping

• Map the shared Stable Audio contract to the pinned upstream PyTorch API for music, SFX, audio-to-audio, continuation, inpainting, prompts, negative prompts, seeds, duration, steps, CFG/APG-related controls, Small/Medium, LoRA, progress, and cancellation.
• Verify every control against the exact pinned API. The current source exposes APG-related behavior, but if a required feature is missing from the pinned dependency, contribute/coordinate upstream or route that operation explicitly to TFLite; do not carry a private fork.
• Reuse parity fixtures from Add a portable Stable Audio 3 TFLite backend #111 and document any intentional backend difference.

GPU scheduling and isolation

• Add a GPU resource broker shared with MRT2 scheduling.
• Base reservations/eligibility on measured per-model VRAM use with conservative headroom; treat reported free VRAM as advisory because unrelated applications can change it.
• Keep MRT2 deck generation higher priority than background Stable Audio work.
• Contain CUDA OOM, driver reset, cancellation, and worker crash to the Stable Audio worker; these failures must not interrupt deck audio or kill MRT2 workers.
• Release worker/process resources and VRAM after completion, cancellation, backend switch, app exit, and failure.

Model support and fallback

• Small Music and Small SFX are required for qualification.
• Medium is optional and may be enabled only on explicitly validated hardware/VRAM configurations; otherwise route it to TFLite with a clear explanation.
• Do not add unofficial FlashAttention builds, custom CUDA extensions, or a maintained model fork to make Medium pass.
• Tie model/runtime/LoRA technical provenance to immutable revisions and provide it to Add third-party model licensing, attribution, and download acknowledgement #108's UI flow.

Backend selection UX

• Provide Auto, GPU, and CPU/TFLite choices with the active backend visible.
• Auto must make a conservative, explainable decision and fall back before starting when the GPU configuration is known to be unsafe.
• Explicit GPU mode must fail clearly or offer a user-confirmed fallback; it must not silently change semantics.
• Surface estimated VRAM need, detected GPU/driver/runtime, worker state, and fallback reason in diagnostics.

Tests and benchmarks

• Dependency-lock and shared-runtime upgrade tests.
• Shared-contract parity fixtures against TFLite.
• Broker tests using deterministic/fake GPU pressure plus real-hardware validation with unrelated VRAM consumers.
• Cancellation, CUDA OOM, worker crash, VRAM release, fallback, and app-exit cleanup tests.
• Benchmarks while both MRT2 decks run in both scheduling modes; require zero engine-reported underruns.

Acceptance criteria

• The pinned upstream PyTorch Stable Audio dependency coexists in one qualified runtime with MRT2, or this issue records a no-go/blocker instead of shipping duplicate runtime packs.
• Small Music and Small SFX pass the shared feature/parity fixtures on supported Windows NVIDIA hardware.
• Medium is enabled only for validated hardware and otherwise uses a clear TFLite fallback.
• Both decks continue for 10 minutes in both MRT2 scheduling modes with zero engine-reported underruns while GPU Stable Audio work is queued or running according to the broker policy.
• CUDA OOM, cancellation, worker crash, and app exit release the Stable Audio worker/VRAM without disrupting MRT2 or the audio callback.
• Auto/GPU/CPU selection, active backend, requirements, and fallback reasons are visible and diagnosable.
• No LSDJ-maintained fork, unofficial FlashAttention build, or custom CUDA extension is introduced.
• Ship Windows 11 x64 + NVIDIA support #113 remains releasable with TFLite if this issue is incomplete or no-go.

Out of scope

• Replacing the TFLite baseline.
• TensorRT or a custom CUDA port.
• Maintaining a Stable Audio fork or unofficial FlashAttention builds.
• Model training.
• AMD/Intel GPU acceleration.
• Linux GPU Stable Audio acceleration.
• Remote inference or WSL.