feat(audio): native PipeWire capture backend on Linux

[olosegres]

Problem

On Linux, microphone capture is pinned to cpal's ALSA host (get_cpal_host() → HostId::Alsa in audio_toolkit/audio/utils.rs). Handy's capture stream is therefore an ALSA "default" client, and PipeWire never sees it as a first-class node. On the (now near-universal) PipeWire desktop this means:

• The microphone can be far too quiet in Handy specifically. Many built-in laptop mics are weak and are boosted at the PipeWire source (a WirePlumber/filter gain, or a per-source volume). That gain is applied by PipeWire after the node, so it reaches every PipeWire-native app — but not an ALSA "default" client. Handy therefore captures the raw, un-boosted signal and ends up dramatically quieter than every other app on the same mic (near-silent recordings, poor/empty transcriptions), with no in-app way to fix it: raising the source volume with wpctl/pavucontrol has no effect on Handy.
• No per-application capture volume / routing. More generally, the stream has no PipeWire node volume, so it can't be attenuated/boosted per-app or routed to a specific source via wpctl / pavucontrol / WirePlumber — Handy is invisible to all of that.
• Device enumeration only ever shows "default" on many PipeWire systems — the ALSA cpal host doesn't surface the graph's friendly per-source nodes — so the mic selector can't offer the real inputs.
• The ALSA path is also comparatively fragile on PipeWire (silent/empty captures, wedged streams); related symptoms: [BUG] No microphone recording on Pop!_OS 24.04 (PipeWire) – cpal probes OSS but fails to use ALSA input #806, [BUG] Handy occasionally locks up Pipewire on Ubuntu #1349, [BUG] Subsequent recordings don't capture anything #828, [BUG] Microphone not detected on Linux — sof-hda-dsp (hw:0,7) works in Vocalinux but Handy only shows "Default" #1339, [BUG] audio recording issue. Microphone initialize twice #1101.

Change

Add a native PipeWire capture backend (pipewire-rs 0.10) that registers Handy's microphone as a real PipeWire node, so it shows up in wpctl status with its own settable volume and is routable per-app.

• New pipewire_recorder.rs: runs the PipeWire main loop on a dedicated thread (all non-Send pw objects stay on it), negotiates F32, downmixes to mono in the RT process callback, and feeds the existing resampler → VAD → consumer pipeline unchanged via the shared Cmd/AudioChunk protocol. No DSP is reimplemented.
• New recorder_backend.rs (Recorder): a thin seam that selects the backend. On Linux it prefers PipeWire and falls back to the cpal/ALSA path if PipeWire setup fails (e.g. no running session). Non-Linux targets compile cpal-only and are behaviourally unchanged; cpal stays fully compiled as the fallback everywhere.
• pipewire is added only under [target.'cfg(target_os = "linux")'.dependencies] (feature v0_3_44), so Windows/macOS builds are untouched.

Testing

Built and run on Fedora (Asahi, aarch64) under GNOME/Wayland with PipeWire 1.6.8. Hotkey → record → transcribe works end-to-end through the native backend; the log shows Microphone capture using native PipeWire backend, and the capture node appears in wpctl status with a settable volume (wpctl set-volume <id> …) — which the old ALSA client did not support (Node … does not support volume).

Scope / follow-ups

This is an MVP that captures the default source (reproducing today's "default" behaviour). PipeWire-native device enumeration/selection is intentionally deferred — there's a TODO in Recorder::open, where a user-selected mic would map to a node.name passed through TARGET_OBJECT (already threaded through PipeWireRecorder::open). Happy to iterate on device selection and feature-gating in review.

[cjpais]

Thank you I will take a look at this!