fix: always use default_input_config to avoid shared-mode stream rejection

[dan-vernon]

Summary

• Replaces get_preferred_config()'s format-selection logic with a direct call to default_input_config()
• Fixes consistent Failed to build input stream: The requested stream configuration is not supported by the device error on macOS and Windows

Problem

get_preferred_config() iterated supported_input_configs() and picked the highest-scored sample format (preferring F32 over I16). However, supported_input_configs() enumerates exclusive-mode formats on both CoreAudio (macOS) and WASAPI (Windows). Since cpal opens streams in shared mode, the OS requires the stream to use the mixer's native format — which is what default_input_config() returns. Passing a different format caused build_input_stream to fail immediately on every attempt.

This root cause was identified by @VirenMohindra in #990. The existing FrameResampler in run_consumer() already handles downsampling to the 16 kHz rate required by Whisper/Parakeet, so no other changes are needed.

Testing

• Tested locally on macOS 26 with built-in mic
• Tested with standard transcription and post-processing modes
• rustfmt --check passes
• Existing unit tests unaffected (they test string matching helpers, not device config)

Related issues

Closes #990

AI assistance

This PR was written with the help of Claude Code. It was used extensively — log analysis, root cause diagnosis, code change, and PR writeup.

[VirenMohindra]

what was the reasoning behind closing this PR - did the fix not work?

[dan-vernon]

what was the reasoning behind closing this PR - did the fix not work?

Hey @VirenMohindra - same error reoccurred after subsequently testing the fix with a Bluetooth input device, so I need to isolate this from a possible MacOS bluetooth / CoreAudio issue before re-opening. Thx

[dan-vernon]

Reopening with additional retry with I16 if stream creation still fails

Looking through git blame, the old implementation came from two separate changes. First, an explicit format preference (F32 > I16 > I32) when the recorder was still trying to open directly at 16 kHz. Later, this switched to the device’s default sample rate and relied on run_consumer() to downsample, but kept that format-preference heuristic. That combination turns out not to be robust,

The root issue is that the old get_preferred_config() walked supported_input_configs() and preferred F32 over I16. That is not robust with the current cpal backend: enumeration can advertise F32 while default_input_config() reports the actual device format as I16. That mismatch can cause build_input_stream() to fail immediately.

Using default_input_config() fixes the reproduced macOS failure by deferring to the device's native/default format. The existing FrameResampler still handles conversion to the 16 kHz rate required by Whisper/Parakeet, so downstream processing is unchanged.

The new I16 retry is the additional change in this reopening. It is a defensive fallback for cases where the default format is still rejected at stream-open time. It improves robustness, but it is not meant as a claim that every backend or device-state issue is now covered.

For Windows, to be precise: this is still the safer, more API-aligned behaviour for shared-mode capture, but the exact failure mode reproduced here was on macOS, not tested on WASAPI.

Validation so far:

• tested with the built-in mic and normal transcription/post-processing flows on macOS
• confirmed effective during a window where a Bluetooth device was actively in HFP mode and the old code was failing
• consistent HFP reproduction is difficult to force on demand because it depends on external Bluetooth/VOIP/OS state
• cargo test --manifest-path src-tauri/Cargo.toml --lib passes with 62 tests
• cargo fmt --manifest-path src-tauri/Cargo.toml --check passes

Overall assessment: strong confidence for the observed macOS bug, lower risk because this mostly removes custom config-selection logic, but still limited by the lack of automated hardware-level coverage.

[VirenMohindra]

thanks for the comment and the context -- im just not too sure about this one. we added custom code for a reason in #1084

always a fan of removing cruft, but we set this up for a reason to fix a number of other issues

what do you think @cjpais

[cjpais]

this is effectively a dead function now

[cjpais]

@VirenMohindra I will need more time with this one, or we need to get a test build out to everyone with this

I am generally in favor of using default configs always if possible. I do suspect it will help avoid some issues, but not sure if it will cause others. We just need to make sure Handy can handle the cases for the new configs it might be thrown

[github-actions]

🧪 Test Build Ready

Build artifacts for PR #1163 are available for testing.

Download artifacts from workflow run

Artifacts expire after 30 days.