Bluetooth headset mic: crash ("Failed to create tap due to format mismatch") or endless restart loop when starting mic tracking
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- macos, swift
- Área
- audio-video-rtc, desktop
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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!
- Lenguaje dominante
- Swift
- Estrellas
- 4k
- Forks
- 271
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de f/textream
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 74/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
Todos los issues de f/textream
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Los mantenedores suelen responder en 1 día
-
bug milestone-qa mobile
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
lognorman20/monaco#4011 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 67/100
Cocoanetics/SwiftScript#22 ·
-
🚀 [firebase_core] Bump Firebase iOS SDK (12.19.0 → 13.0.0)Posiblemente ocupada @SelaseKay la tomó hoy. AbiertoNeeds Attention type: enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
firebase/flutterfire#18769 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
🎉 Add NijiaAbiertoaddition
Dificultad 1/5 1-3 horas Aptitud para principiantes 68/100
jaywcjlove/awesome-mac#3269 ·
Los mantenedores suelen responder en 1 día