mirror of
https://github.com/rowboatlabs/rowboat.git
synced 2026-07-24 21:41:08 +02:00
342504e12b
Meeting transcription failed on Linux because the system-audio side of the recorder was unreliable there. Two real problems, neither of which was the one proposed in the issue: - desktopCapturer.getSources() goes through the Wayland screencast portal, which can block on a system dialog or hang outright. Audio-only display-media requests (meeting transcription discards the video track) now answer with the requesting frame as the mandatory video source and Chromium's PulseAudio loopback for audio - no portal involved. - Chromium captures loopback audio at the default sink's monitor-source volume. Desktop tools sometimes leave that volume near zero, which turns the capture into digital silence with no error anywhere. Before capture starts, ensureLinuxMonitorVolume() raises it back to 100% (raise-only, best-effort via pactl). The issue's proposed fix - enumerating PipeWire/Pulse monitor sources via enumerateDevices() and capturing with getUserMedia - is not viable: Chromium filters monitor sources out of input-device enumeration on Linux (audio_manager_pulse.cc), so they never appear. Verified against Electron 39 / Chromium 142 that audio:'loopback' works on Linux through the Pulse layer (PipeWire's pipewire-pulse or classic PulseAudio). On Linux the loopback track mirrors the output device rather than the meeting app, so "ended" never fires when the meeting closes; auto-stop relies on the existing silence detector. Capture failures now surface a toast pointing at PipeWire/PulseAudio instead of silently going idle. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| cli | ||
| docs | ||
| experimental | ||
| python-sdk | ||
| rowboat | ||
| rowboatx | ||
| x | ||