Bluetooth headset mic: crash ("Failed to create tap due to format mismatch") or endless restart loop when starting mic tracking
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 42/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- macos, swift
- Ambito
- audio-video-rtc, desktop
Direzione di ricerca
Start in SpeechRecognizer.beginRecognition() and trace the audio-engine configuration-change observer through restartRecognition() and cleanupRecognition(). Reproduce with a Bluetooth headset switching from A2DP to HFP, then verify startup no longer crashes or restarts continuously and that repeated configuration changes are bounded. The issue also identifies the microphone picker’s saved-device UID as a related behavior to check.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
When the microphone is a Bluetooth headset (AirPods-style earbuds), starting mic-based practice either:
- crashes with an uncaught AVFAudio exception, or
- loops: the app stays up but tears down and restarts the audio engine continuously, about 50 CoreAudio errors per second.
Both come from the same trigger. Opening a Bluetooth mic makes macOS switch the headset from A2DP (stereo, 44.1/48 kHz, no mic) to HFP (16 kHz mono) while beginRecognition() is running.
Environment
- Textream 1.7.1 (official notarized DMG, commit
2c02f3e) - macOS 27.2, Apple Silicon
- Mic: Technics EAH-AZ100 (Bluetooth earbuds). Should reproduce with any Bluetooth headset that switches to HFP when its mic opens.
- Listening mode: default (word tracking), practice from the main window
Steps to reproduce
- Connect Bluetooth earbuds while they're playing in A2DP mode.
- Either leave Textream's mic on the system default (earbuds as system input), or select the earbuds explicitly in Settings → Microphone.
- Start practice with the microphone.
Expected: mic tracking starts, perhaps after a short pause while the headset switches profile.
Actual: crash (explicit selection, below) or a continuous restart loop (system default, below).
1. Crash: uncaught exception from installTap
*** Terminating app due to uncaught exception 'com.apple.coreaudio.avfaudio',
reason: 'Failed to create tap due to format mismatch, <AVAudioFormat: 1 ch, 44100 Hz, Float32>'
3 AVFAudio AVAudioEngineGraph::InstallTapOnNode(...)
4 AVFAudio -[AVAudioNode installTapOnBus:bufferSize:format:error:block:]
5 Textream ...
8 libdispatch _dispatch_call_block_and_release (queued scheduleBeginRecognition work item)
In SpeechRecognizer.beginRecognition():
hardwareFormat = inputNode.outputFormat(forBus: 0)(line ~479) is read while the headset still reports its pre-switch 44.1 kHz format.speechCaptureFormat(for:)builds a 1 ch / 44.1 kHz tap format from it.- By the time
inputNode.installTap(onBus:bufferSize:format:)runs (line ~521), the device is in HFP at 16 kHz. AVFAudio raises an Objective-C exception, which Swift can't catch, so the process aborts.
With an explicit selection this is more likely. The code switches device via kAudioOutputUnitProperty_CurrentDevice + AudioUnitUninitialize/Initialize (lines ~406-424) and then reads the format straight away, before the HFP switch has settled.
2. Endless restart loop (system-default mic)
The unified log shows a steady stream of:
Textream (CoreAudio) throwing -10877 # ~593 times in 30 min, ~50/s while active
AUHAL UpdateStreamFormats ... 1 ch, 16000 Hz # alternating with
AUHAL UpdateStreamFormats ... 2 ch, 44100 Hz
The cycle:
beginRecognition()opens the mic, so the headset switches A2DP → HFP andAVAudioEngineConfigurationChangefires.- The observer (line ~501-511) calls
restartRecognition(), which runscleanupRecognition(). That closes the mic, and the headset switches back to A2DP. scheduleBeginRecognition(after: 0.5)reopens the mic, the headset switches to HFP again, and the cycle repeats.
Two details keep it from ever stopping:
restartRecognition(resetRetryCount: true)is the default, and the observer uses it. SoretryCountis reset to 0 on every config change, andmaxRetriesnever caps the loop (lines ~637-639).suppressConfigChangeis only set on the explicit-mic-selection path (line ~409). With the system default, the HFP switch caused by our own mic open is treated as an external change.
There's also a minor related problem: Settings → Microphone logs Picker: the selection "<BT-address>:input" is invalid and does not have an associated tag for the saved Bluetooth mic UID. The picker can therefore show a different device from the one actually in use.
Suggested fixes
- Make the tap install non-fatal:
- read the format immediately before
installTapand compare it withinputNode.inputFormat(forBus: 0); or - install the tap with
format: nil(the node's current format) and downmix/resample in the tap withAVAudioConverter; or - wrap
installTapin a small Objective-C@try/@catchshim and treat a mismatch like the existing invalid-format guard (retry after a settle delay).
- read the format immediately before
- Don't reset
retryCountfrom the config-change observer. CallrestartRecognition(resetRetryCount: false)there and add backoff, so a device that keeps flapping ends infailListening(...)instead of looping. - Treat the first config change after our own engine start as expected. Suppress or debounce config changes for roughly 1-2 s after
audioEngine.start()on all paths, not only explicit mic selection, because opening a Bluetooth mic always triggers the profile switch. - Make sure the microphone picker includes the saved device UID, or falls back visibly to the system default.
Workaround (untested)
Keep the headset in HFP before starting Textream, so the format doesn't change during startup. For example, open QuickTime → New Audio Recording with the headset selected, without recording. Using the built-in mic or a wired/USB mic avoids the problem completely.
Happy to test a build. Thanks for Textream!
- Lingua principale
- Swift
- Stelle
- 4k
- Fork
- 271
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di f/textream
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 74/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 25/100
Issue simili
-
#️⃣ REX and feebacks 🔍 triage 🧑💻 Developer eXperience 🧰 library
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Orange-OpenSource/ouds-ios#1795 ·
I maintainer di solito rispondono entro 1 giorno
-
bug milestone-qa mobile
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
lognorman20/monaco#3519 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
FuzzyIdeas/Cling#33 ·
-
Bug Needs Triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
mastodon/mastodon-ios#1572 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno