[BUG] FluidVoice 1.6.5 hangs when switching between a preferred microphone and AirPods

[dain]

Describe the bug

FluidVoice 1.6.5 build 16 can become completely unresponsive during audio-route recovery when I have a Shure MV7+ selected as the preferred microphone and AirPods Max connected.

This is a follow-up to #624 and #644. It appears different from the earlier AVAudioEngine deallocation deadlock: in this occurrence, the old engine was retired successfully, but the replacement engine then blocked while accessing AVAudioEngine.inputNode.

The application remained hung for approximately 3 minutes 32 seconds. Taking off my AirPods, which triggered another macOS audio-route change, caused it to recover without being force-quit.

Reproduction steps

I have only observed this exact hang once, so it may require a specific timing-dependent race and I do not yet have reliably repeatable steps.

The environment when it occurred was:

1. A Shure MV7+ was connected directly to the Mac and selected as FluidVoice's preferred microphone.
2. AirPods Max were connected and being used for audio output.
3. I started a FluidVoice recording.
4. FluidVoice reasserted the preferred Shure input, and macOS generated an audio-route change.
5. FluidVoice entered active audio-route recovery and became completely unresponsive.

The application remained hung for approximately 3 minutes 32 seconds. Taking off my AirPods triggered another macOS audio-route change, after which FluidVoice recovered without being force-quit.

Expected behavior

FluidVoice should continue using the selected Shure microphone and remain responsive when AirPods connect, disconnect, or otherwise cause macOS to reconfigure the audio route.

If recovery is required, it should complete or fail without indefinitely blocking the application.

Actual behavior

FluidVoice became completely unresponsive while rebuilding its audio engine.

The application log stopped immediately after:

Forcing input node instantiation...

A 10-second process sample taken during the hang showed every sample of the active recovery thread blocked in:

ASRService.configureSession
-> AVAudioEngine.inputNode
-> AVAudioEngineImpl::UpdateInputNode
-> AVAudioIONodeImpl::GetInputFormat
-> AVAudioIOUnit::GetHWFormat
-> Core Audio property queries

The AVAudioEngine serial queue was simultaneously waiting in IOUnitConfigurationChanged.

After approximately 3 minutes 32 seconds, taking off the AirPods triggered another audio-route change. The blocked inputNode call then returned and FluidVoice recovered.

App Version

1.6.5 (build 16)

macOS Version

macOS 26.5.2 (25F84)

Architecture

Apple Silicon

Logs or crash report

I captured a live process sample and correlated FluidVoice/Core Audio logs while the application was hung.

Relevant timeline:

10:19:50.686  Preferred Shure microphone reasserted during recording start
10:19:50.821  Initial AVAudioEngine configuration completed
10:19:51.570  Route change detected while recording
10:19:52.005  Active route recovery began
10:19:52.011  Previous audio engine retired
10:19:52.030  Forcing input node instantiation...
               [no progress for approximately 3 minutes 32 seconds]
10:23:23.606  Input node instantiated after AirPods removal
10:23:23.729  Audio-route recovery succeeded

The compatibility AVAudioEngine backend was active:

audio_backend kind=av_audio_engine_fallback reason=experimental_disabled

At the same time, Core Audio reported a transitional device with no input or output, an error setting the device on the I/O unit, inconsistent channel-layout information, and an invalid IOProcStreamUsage property size.

The attached sanitized diagnostics bundle contains the complete process sample, focused application logs, focused Core Audio logs, and a README with analysis.

Screenshots or screen recording

fluid-hang-diagnostics-2026-07-24-1021.zip