fix(audio): bump cpal 0.16→0.17 to fix device-enumeration crash on macOS 26 (Tahoe)

[xronocode]

Before Submitting This PR

• I have searched existing issues and pull requests (including closed ones) to ensure this isn't a duplicate
• I have read CONTRIBUTING.md

Duplicate search done: no open or closed issue/PR covers the macOS 26 (Tahoe) CoreAudio device-enumeration segfault or a cpal 0.16→0.17 bump. Closest issues are Linux-specific OSS/ALSA/PipeWire (#806, #1339, #1349).

Human Written Description

Handy crashes hard on launch on macOS 26 (Tahoe) — it segfaults while enumerating audio devices, so the app is unusable there at all. I traced it down to cpal 0.16's CoreAudio path (coreaudio-rs 0.13); bumping cpal to 0.17 (and rodio to 0.22 so the whole tree shares one cpal) makes it survive device enumeration and run normally. This is a straight crash on a current macOS, so I wanted to get it upstream.

Related Issues/Discussions

Fixes #1643

Community Feedback

This is a bug fix (top priority per CONTRIBUTING) for a hard crash on macOS 26 (Tahoe). Not previously reported upstream; surfacing it as a fix alongside the bug report.

Testing

Root cause verified: cpal 0.16 (via coreaudio-rs 0.13) segfaults in CoreAudio device enumeration on macOS 26. cpal 0.17 pulls coreaudio-rs 0.14, which resolves it. Verified the tree now resolves to a single cpal v0.17.3 (shared by the direct dep and rodio v0.22.2) — cargo tree -i cpal confirms no duplicate cpal version.

Build verification (on main @ 9b0d8a1):

• cargo check --locked → 0 errors
• cargo clippy --locked → no new lints (only pre-existing device.name() deprecation notes — see note below)
• cargo fmt --check → clean
• cargo tree -i cpal → single cpal v0.17.3

Manual verification needed (hardware/macOS): launch on macOS 26, open Settings → Audio — the app must survive device enumeration with no SIGSEGV. Before this patch the crash was deterministic within ~15–22s of launch.

Scope: 4 files — Cargo.toml (2 dep lines), Cargo.lock (regenerated), recorder.rs (1 line: SampleRate became a u32 alias in 0.17), audio_feedback.rs (5 lines: rodio 0.22 renamed OutputStreamBuilder → DeviceSinkBuilder). No recording/enumeration logic changed; Linux host selection (get_cpal_host() → ALSA) is untouched.

Cross-platform note: cpal 0.17 + rodio 0.22 are current upstream releases; the change is platform-agnostic at the API level (only the SampleRate tuple→alias and the rodio builder rename). The cjpais/rodio fork (rodio 0.20, which pinned cpal 0.16) is dropped in favor of upstream rodio 0.22.

Known follow-up (intentionally NOT in this PR): cpal 0.17 deprecates Device::name() in favor of description()/id(). That migration is not a drop-in — description() returns richer strings (name + manufacturer) that could stop matching saved selected_microphone/selected_output_device settings, so it deserves its own PR and separate testing. Left as 4 deprecation warnings for now.

Screenshots/Videos (if applicable)

Native SIGSEGV crash produces no in-app visual; repro is "launch on macOS 26 → Settings → Audio → SIGSEGV". Happy to capture a no-crash video on request.

AI Assistance

• AI was used (please describe below)

If AI was used:

• Tools used: Claude (Kilo CLI) for analysis, patch porting, and verification; the same fix was independently shipped and verified in production in a downstream fork (TokMo).
• How extensively: AI assisted with identifying the cpal 0.16/coreaudio-rs 0.13 root cause, porting the dependency bump and the two API-break fixups onto current main, and running the build/clippy/fmt verification. The crash reproduction and the decision to migrate to cpal 0.17 were driven by real macOS 26 hardware testing in the fork.

[cjpais]

Most likely, this cannot be merged as is largely because there are other changes in the libraries that affect other platforms that we have to be aware of and need to be testing, especially as it goes to device enumeration. So, certainly this can't be pulled in as is and I do still need more information about your specific system

[xronocode]

Agreed, and thanks for calling that out. This should be treated cautiously because the dependency bump affects audio backends beyond the specific macOS crash I hit.

The patch itself is intentionally small: cpal 0.16 -> 0.17, moving rodio off the cpal-0.16-pinned fork to rodio 0.22, plus the two required API fixups (SampleRate and DeviceSinkBuilder). I did not change Handy's device-enumeration or recording logic directly.

What I verified locally:

• cargo check --locked passes
• the macOS crash no longer reproduces on my affected machine
• the affected machine has virtual devices installed: BlackHole 2ch and Xronophone Microphone, plus built-in devices

What I have not verified:

• Linux audio backends
• Windows audio backends
• a wider macOS device matrix

So I agree this may not be merge-ready without broader testing. If there is a specific test matrix or smoke test you want run for Linux/Windows/macOS, I can help with the parts I can reproduce locally and keep the PR scoped to the dependency bump only.

[xronocode]

Hi @cjpais, gentle nudge on this one. I know you flagged that the cpal 0.16 to 0.17 bump pulls in other library changes that need care. Happy to do that legwork if it helps: I can rebase on current main, run the full build and tests locally, and write up exactly which transitive deps changed and what I verified, so there's less for you to dig through. Let me know if that's useful or if you'd rather take it a different way. No rush.

[cjpais]

I mean, if you want to take this up and are serious about getting this in, I need you to basically reach out across platforms and get validation on a wide range of devices from people in the community. It's just unlikely I can make a dependency bump without large amounts of testing because it seems likely to bring in new bugs that at the moment I'm not really willing to because, as far as I can tell, you're one of the only people running into the crash. Either that or I need more reports on the crash itself to make it a higher priority. But right now, this is just not a priority. There are so many other issues that are affecting more users with less risk, so that has to take my priority at the end of the day