feat(package): make NemoTextProcessing an opt-out trait for ASR-only consumers (#880, #888) - #892

Supertonic3 Smoke Test ✅

_{Runtime: 0m29s}

_{Note: CI VMs lack a physical Neural Engine; the ANE-bucketed VectorEstimator falls back to CPU here. This validates download + variant resolution + synthesis, not ANE residency/perf.}

VAD Benchmark Results

Performance Comparison

Dataset Details

• MUSAN: Music, Speech, and Noise dataset - standard VAD evaluation
• VOiCES: Voices Obscured in Complex Environmental Settings - tests robustness in real-world conditions

✅: Average F1-Score above 70%

Speaker Diarization Benchmark Results

Speaker Diarization Performance

Evaluating "who spoke when" detection accuracy

Diarization Pipeline Timing Breakdown

Time spent in each stage of speaker diarization

Speaker Diarization Research Comparison

Research baselines typically achieve 18-30% DER on standard datasets

Note: RTFx shown above is from GitHub Actions runner. On Apple Silicon with ANE:

• M2 MacBook Air (2022): Runs at 150 RTFx real-time
• Performance scales with Apple Neural Engine capabilities

_{🎯 Speaker Diarization Test • AMI Corpus ES2004a • 1049.0s meeting audio • 61.3s diarization time • Test runtime: 2m 35s • 09/08/2026, 08:07 PM EST}

Sortformer High-Latency Benchmark Results

ES2004a Performance (30.4s latency config)

_{Sortformer High-Latency • ES2004a • Runtime: 2m 48s • 2026-09-08T23:57:04.794Z}

Parakeet EOU Benchmark Results ✅

Status: Benchmark passed
Chunk Size: 320ms
Files Tested: 100/100

Performance Metrics

Streaming Metrics

_{Test runtime: 0m49s • 09/08/2026, 07:54 PM EST}

_{RTFx = Real-Time Factor (higher is better) • Processing includes: Model inference, audio preprocessing, state management, and file I/O}

PocketTTS Smoke Test ✅

_{Runtime: 0m7s}

_{Note: PocketTTS uses CoreML MLState (macOS 15) KV cache + Mimi streaming state. CI VM lacks physical GPU — audio quality and performance may differ from Apple Silicon.}

Offline VBx Pipeline Results

Speaker Diarization Performance (VBx Batch Mode)

Optimal clustering with Hungarian algorithm for maximum accuracy

Offline VBx Pipeline Timing Breakdown

Time spent in each stage of batch diarization

Speaker Diarization Research Comparison

Offline VBx achieves competitive accuracy with batch processing

Pipeline Details:

• Mode: Offline VBx with Hungarian algorithm for optimal speaker-to-cluster assignment
• Segmentation: VAD-based voice activity detection
• Embeddings: WeSpeaker-compatible speaker embeddings
• Clustering: PowerSet with VBx refinement
• Accuracy: Higher than streaming due to optimal post-hoc mapping

_{🎯 Offline VBx Test • AMI Corpus ES2004a • 1049.0s meeting audio • 99.2s processing • Test runtime: 1m 48s • 09/08/2026, 08:01 PM EST}

ASR Benchmark Results ✅

Status: All benchmarks passed

Parakeet v3 (multilingual)

Parakeet v2 (English-optimized)

Streaming (v3)

Streaming (v2)

_{Streaming tests use 5 files with 0.5s chunks to simulate real-time audio streaming}

_{25 files per dataset • Test runtime: 20m4s • 09/08/2026, 08:15 PM EST}

_{RTFx = Real-Time Factor (higher is better) • Calculated as: Total audio duration ÷ Total processing time
Processing time includes: Model inference on Apple Neural Engine, audio preprocessing, state resets between files, token-to-text conversion, and file I/O
Example: RTFx of 2.0x means 10 seconds of audio processed in 5 seconds (2x faster than real-time)}

Expected RTFx Performance on Physical M1 Hardware:

• M1 Mac: ~28x (clean), ~25x (other)
• CI shows ~0.5-3x due to virtualization limitations

_{Testing methodology follows HuggingFace Open ASR Leaderboard}

Ran the before/after I offered in #888. Universal release build of our macOS app, Xcode 26.3 / Swift 6.2.4, same tree and same app version for both, PR head 97c6e82, only the traits: line differs.

That's 16.85 MB off the universal executable, 8.36 MB off arm64 and 8.48 MB off x86_64, or 12.7% of the binary. The .app bundle drops the same 16.8 MB (650.6 to 633.8 MB). Same order as your fluidaudiocli numbers. These are the as-built release binaries with no extra strip -x, so they run a bit larger than yours.

Nothing regressed on the ASR side. AsrManager, StreamingAsrManager and DiarizerManager symbols are all still in both slices, and we don't reference TextNormalizer anywhere.

Two things worth knowing, neither a blocker.

Xcode projects can't set traits. We consume FluidAudio as an XCRemoteSwiftPackageReference in an .xcodeproj, and Xcode 26.3 has nowhere to put traits: []: no UI for it, no pbxproj key. Trait support seems to have landed in 26.4, which I haven't tested. What worked was a one-target local package that declares the dependency and re-exports the module, with the app target linking that instead of FluidAudio directly:

// swift-tools-version: 6.2
let package = Package(
    name: "FluidAudioShim",
    platforms: [.macOS(.v14), .iOS(.v17)],
    products: [.library(name: "FluidAudioShim", targets: ["FluidAudioShim"])],
    dependencies: [
        .package(url: "https://github.com/FluidInference/FluidAudio.git", from: "0.15.7", traits: [])
    ],
    targets: [
        .target(name: "FluidAudioShim", dependencies: [.product(name: "FluidAudio", package: "FluidAudio")])
    ]
)

with @_exported import FluidAudio as the target's only source file, so existing import FluidAudio lines keep compiling. Might be worth a couple of lines in the "Opting out" section, since app consumers are more likely to be Xcode projects than packages.

The xcframework still downloads. With a cold --cache-path, traits: [] still fetches and extracts the 49 MB NemoTextProcessing.xcframework.zip. The binary target is declared unconditionally and only the dependency edge is trait-conditioned, so resolution pulls it either way. Ship size is fixed, but CI and clean checkouts still pay for the download. Probably a SwiftPM limitation rather than something this PR can address.

One caveat on our end: this is a build and symbol check, not a live session run. The link succeeded and our ASR path never touched the engine, so I'd be surprised by a runtime difference, but I haven't proven one way or the other yet.