fix(diarizer/offline): warn on macOS 14 BNNS-crash-prone builds + document known OS issue (#878) - #885
Conversation
…ument known OS issue (#878) Library-side portion of #878 (follow-up to #661/#817 family). JulianPscheid's CI matrix proved the offline diarizer libBNNS crash (EXC_BAD_ACCESS in BNNSGraphContextExecute_v2 -> _platform_memmove) is an Apple OS bug in the macOS 14 line: 1200/1200 crashes on macos-14 runners across every variant (unpatched v0.15.5, Core ML-owned FBank storage, fully serialized single-model runs), 0/N on macos-15 and macos-26. On VMs without an ANE every prediction takes the BNNS CPU path, making the crash deterministic; on Apple Silicon it is intermittent because only ANE-fallback predictions hit BNNS. No serialization or compute-unit routing avoids it; Apple fixed it in macOS 15. Since no library-side mitigation exists, the honest fix is diagnosis (same approach as #818 for the separate 26.4-26.5 Kokoro BNNS bug): - OfflineDiarizerManager.initialize(models:) warns on macOS 14 builds pointing at #878, so field crashes get attributed to the OS instead of usage patterns or FluidAudio versions. Predicate extracted as isBnnsCrashProneOS(_:onMacOS:) for testability; iOS is unflagged since no reproduction has been reported on the iOS 17 line. - OfflineDiarizerOsAdvisoryTests: boundary coverage (13.6 / 14.0 / 14.8.7 / 15.0 / 26.5.2, iOS unflagged). - Documentation/Diarization/GettingStarted.md: Known OS issue note in the Offline VBx section, distinguishing this bug from the Kokoro 26.4-26.5 class. - Cross-ref comment at the FBank .cpuOnly pin, which is why the diarizer is the component that surfaces this on macOS 14. swift build green; swift format lint clean on touched files. Tests run in CI (XCTest unavailable locally).
PocketTTS Smoke Test ✅
Runtime: 0m20s 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. |
Supertonic3 Smoke Test ✅
Runtime: 0m32s 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. |
Parakeet EOU Benchmark Results ✅Status: Benchmark passed Performance Metrics
Streaming Metrics
Test runtime: 1m35s • 08/31/2026, 11:26 PM EST RTFx = Real-Time Factor (higher is better) • Processing includes: Model inference, audio preprocessing, state management, and file I/O |
Speaker Diarization Benchmark ResultsSpeaker Diarization PerformanceEvaluating "who spoke when" detection accuracy
Diarization Pipeline Timing BreakdownTime spent in each stage of speaker diarization
Speaker Diarization Research ComparisonResearch baselines typically achieve 18-30% DER on standard datasets
Note: RTFx shown above is from GitHub Actions runner. On Apple Silicon with ANE:
🎯 Speaker Diarization Test • AMI Corpus ES2004a • 1049.0s meeting audio • 40.2s diarization time • Test runtime: 3m 6s • 08/31/2026, 11:29 PM EST |
Offline VBx Pipeline ResultsSpeaker Diarization Performance (VBx Batch Mode)Optimal clustering with Hungarian algorithm for maximum accuracy
Offline VBx Pipeline Timing BreakdownTime spent in each stage of batch diarization
Speaker Diarization Research ComparisonOffline VBx achieves competitive accuracy with batch processing
Pipeline Details:
🎯 Offline VBx Test • AMI Corpus ES2004a • 1049.0s meeting audio • 130.4s processing • Test runtime: 2m 24s • 08/31/2026, 11:34 PM EST |
Sortformer High-Latency Benchmark ResultsES2004a Performance (30.4s latency config)
Sortformer High-Latency • ES2004a • Runtime: 5m 16s • 2026-09-01T03:35:46.995Z |
VAD Benchmark ResultsPerformance Comparison
Dataset Details
✅: Average F1-Score above 70% |
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: 11m8s • 08/31/2026, 11:43 PM EST RTFx = Real-Time Factor (higher is better) • Calculated as: Total audio duration ÷ Total processing time Expected RTFx Performance on Physical M1 Hardware:• M1 Mac: ~28x (clean), ~25x (other) Testing methodology follows HuggingFace Open ASR Leaderboard |
Library-side portion of #878 (the #661/#817 BNNS crash family).
Context
@JulianPscheid's CI matrix in #878 proves the offline diarizer
libBNNScrash (EXC_BAD_ACCESSinBNNSGraphContextExecute_v2→_platform_memmove) is an Apple OS bug in the macOS 14 line:.ipsartifacts.Changes
Since no library-side mitigation exists, the honest fix is diagnosis — same approach as #818 took for the (distinct) 26.4–26.5 Kokoro BNNS bug:
OfflineDiarizerManager.initialize(models:)logs a warning on macOS 14 builds pointing at Offline diarizer BNNS crash (#661 family) reproduces deterministically on macOS 14; absent on 15 and 26 #878, so field crashes get attributed to the OS instead of usage patterns or FluidAudio versions. Predicate extracted asisBnnsCrashProneOS(_:onMacOS:)for testability. iOS is unflagged — no reproduction has been reported on the iOS 17 line.OfflineDiarizerOsAdvisoryTests— boundary coverage (13.6 ✗ / 14.0 ✓ / 14.8.7 ✓ / 15.0 ✗ / 26.5.2 ✗; iOS unflagged).Documentation/Diarization/GettingStarted.md— "Known OS issue" note in the Offline VBx section: macOS 14 can crash in BNNS regardless of usage pattern, fixed by updating to macOS 15+; explicitly distinguished from the Kokoro 26.4–26.5 class inKokoroAne.md..cpuOnlypin (OfflineDiarizerModels.swift), which is why the diarizer is the component that surfaces this on macOS 14.Deliberately not changed: FBank routing on macOS 14. The matrix shows every compute-unit configuration crashes there, so a placement tweak would be an unverifiable non-fix; if we want to test whether
.cpuAndGPUFBank reduces exposure on real hardware, the reporter'sworkflow_dispatchharness can take a revision input.Verification
swift buildgreen,swift format lintclean on touched files.Closes nothing on its own — #878 disposition (close as OS bug vs. keep open for Apple Feedback tracking) is up for discussion.
🤖 Generated with Claude Code