Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Bluetooth headset mic: crash ("Failed to create tap due to format mismatch") or endless restart loop when starting mic tracking

オープン
#129 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
macos, swift

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

Summary

When the microphone is a Bluetooth headset (AirPods-style earbuds), starting mic-based practice either:

  1. crashes with an uncaught AVFAudio exception, or
  2. 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
  1. Connect Bluetooth earbuds while they're playing in A2DP mode.
  2. Either leave Textream's mic on the system default (earbuds as system input), or select the earbuds explicitly in Settings → Microphone.
  3. 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:

  1. beginRecognition() opens the mic, so the headset switches A2DP → HFP and AVAudioEngineConfigurationChange fires.
  2. The observer (line ~501-511) calls restartRecognition(), which runs cleanupRecognition(). That closes the mic, and the headset switches back to A2DP.
  3. 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. So retryCount is reset to 0 on every config change, and maxRetries never caps the loop (lines ~637-639).
  • suppressConfigChange is 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 installTap and compare it with inputNode.inputFormat(forBus: 0); or
    • install the tap with format: nil (the node's current format) and downmix/resample in the tap with AVAudioConverter; or
    • wrap installTap in a small Objective-C @try/@catch shim and treat a mismatch like the existing invalid-format guard (retry after a settle delay).
  • Don't reset retryCount from the config-change observer. Call restartRecognition(resetRetryCount: false) there and add backoff, so a device that keeps flapping ends in failListening(...) 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!

主要言語
Swift
スター
4k
フォーク
271
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

f/textream のほかの issue

f/textream の issue をすべて見る

似ている issue

Swift の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。