fix(itn): link the bundled NeMo engine directly instead of dlopen(nil) discovery - #867
Conversation
…) discovery TextNormalizer resolved nemo_* symbols at runtime via dlopen(nil) + dlsym, a leftover from when the native library was an optional consumer-provided link. Since #790 the NemoTextProcessing xcframework ships with the package as a binary target, so runtime discovery is pure downside: - releases <= 0.15.5 shipped no artifact at all, making normalize() a silent no-op for every SwiftPM consumer (issue #839) - even with the bundled lib, dlsym silently regresses to the no-op in any app that strips global symbols from its executable (common in Release) - normalizeSentence(_:maxSpanTokens:) looked up nemo_normalize_sentence_with_max_span, which does not exist in the shipped v0.3.0 library, so the parameter was silently ignored Import CNemoTextProcessing and call the C API directly, like the TTS-side NemoTextNormalizer already does. Availability is now a link-time guarantee; isNativeAvailable/isTnAvailable are kept (always true) for source compat. The max-span variant now calls nemo_normalize_sentence_with_options, which actually honors maxSpanTokens. Tests previously guarded on !isNativeAvailable (permanently skipped once the lib is linked) now assert real engine output, including the exact issue repro: normalize("twelve dollars") == "$12". Expectations verified against the bundled v0.3.0 engine. Fixes #839
Supertonic3 Smoke Test ✅
Runtime: 0m51s 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: 2m20s • 08/19/2026, 10:05 AM EST RTFx = Real-Time Factor (higher is better) • Processing includes: Model inference, audio preprocessing, state management, and file I/O |
VAD Benchmark ResultsPerformance Comparison
Dataset Details
✅: Average F1-Score above 70% |
Sortformer High-Latency Benchmark ResultsES2004a Performance (30.4s latency config)
Sortformer High-Latency • ES2004a • Runtime: 5m 1s • 2026-08-19T14:09:02.933Z |
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 • 57.4s diarization time • Test runtime: 3m 15s • 08/19/2026, 10:13 AM 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: 10m30s • 08/19/2026, 10:13 AM 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 |
PocketTTS Smoke Test ✅
Runtime: 0m32s 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 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 • 167.1s processing • Test runtime: 2m 55s • 08/19/2026, 10:21 AM EST |
Fixes #839
Problem
TextNormalizerresolved thenemo_*symbols at runtime viadlopen(nil)+dlsym— a leftover from when the native ITN library was an optional, consumer-provided link. Since #790 theNemoTextProcessingxcframework ships with the package as a binary target, so runtime discovery is pure downside:normalize()a silent no-op for every SwiftPM consumer (TextNormalizer is a silent no-op for SwiftPM consumers: no native ITN library ships, dlopen(nil) finds nothing, normalize() returns input unchanged (0.15.5) #839). v0.15.6 bundles the xcframework, which fixes standard builds.dlsymsilently regresses to the no-op in any app that strips global symbols from its executable (common in Release configurations) — the symbols are linked in but no longer discoverable.normalizeSentence(_:maxSpanTokens:)looked upnemo_normalize_sentence_with_max_span, which does not exist in the shipped v0.3.0 library, somaxSpanTokenswas silently ignored.Fix
Import
CNemoTextProcessingand call the C API directly, exactly like the TTS-sideNemoTextNormalizeralready does. Availability becomes a link-time guarantee, so the silent-unavailability failure mode is impossible by construction rather than merely logged (issue ask #1).isNativeAvailable/isTnAvailableare kept (alwaystrue) for source compatibility with ≤ 0.15.6 consumers that branch on them.nemo_normalize_sentence_with_options, somaxSpanTokensis actually honored.Tests
Tests that guarded on
!isNativeAvailablebecame permanently-skipped dead code once the library is always linked. They now assert real engine output, including the exact issue repro:Every expectation was verified against the bundled v0.3.0 engine (C driver against the static lib + a compiled Swift check through the real
TextNormalizer): single-expression, sentence mode, max-span, ambiguous-word masking ("the period of growth" preserved), TN surface, and custom rules.Note: consumers get this only with a release cut after merge — v0.15.6 already fixes standard builds, but a follow-up tag carries the strip-proof direct linking.