Question: any plans to bump tract past 0.21.4 (WASM f32 kernel + multithread-mm)?

[czoli1976]

First — genuine thank you for DeepFilterNet. It's an extraordinary piece
of work: the fullband quality at this model size is rare, the ONNX +
tract deployment story makes it actually usable outside of research
contexts, and the maintenance discipline has been visible from the
outside — the 2023 0.19.4 revert (PR #405) after spotting audio
artifacts is exactly the kind of care that builds long-term trust in a
project. Studying the codebase has been a pleasure.

Context

We're evaluating libDF as the inference backend for a browser/WASM
noise-suppression library, and looking into the tract upgrade story
before we commit.

tract 0.21.4 has been pinned since #558 (May 2024). Several items in the
0.21 patch line look directly relevant to WASM inference and threaded
deployments:

• 0.21.6 — "WASM f32 4x4 kernel" (first WASM-specific SIMD kernel
  in the 0.21 line) and a multithreaded matmul runner
• 0.21.8 — MMM kits for matmul + element-wise binary op optimizations
• 0.21.10 — reduce optimizations impacting modern normalization layers
• 0.21.11 — slice bubbling optimizations + improved gather with
  compressed inputs
• 0.21.12 — explicit multithread-mm feature flag in tract-linalg

For a browser/WASM target, 0.21.6's WASM kernel and 0.21.12's threading
flag are the two we're most interested in.

Questions

1. Is there any known reason tract 0.21.5–0.21.15 has not been picked
   up? (PR df: Update tract to 0.20.7 #405's revert message was about a 0.19 → 0.20 jump — very
   different risk profile from a patch bump within the 0.21 line. Have
   there been attempts within 0.21.x since Feat update tract 021 #558?)

2. Would you be open to a PR bumping the pin to ^0.21.12, with:

   • quality validation via DNSMOS on a representative clip corpus
     (~20–30 clips) to rule out audio artifacts like the 2023 case
   • benchmark numbers showing no regression (or ideally, improvement
     on WASM)
   • keeping the minimum-version bound at 0.21.4 for consumers who
     can't follow

3. Any hesitation we should know about — threading caveats (noted
   libDF does not support the Send trait #615's Send concerns), specific opset regressions you've observed,
   or anything else that would shape how we approach validation?

Happy to do the validation work and drive a PR if you're open to the
bump — or park the idea if you'd prefer to keep the pin conservative
for now.

Thank you again for what you've built.

[czoli1976]

I will commit a PR for the Upgrade to 0.21.15