Audio capture goes through PortAudio only: no PipeWire path, no system-audio source

[kacperpaczos]

Same origin as the portal issue I just filed: I was going through what each Voca client uses from its OS.

Capture is PyAudio/PortAudio. PipeWire appears in src/ only as device names to skip — recognition_manager.py:236 filters "pipewire" and the pipewire: prefixes out of the device list, because those pseudo-devices record silence or crash (#53, #444).

Two things follow from having no native PipeWire client.

No system-audio capture. Every input is a microphone. Reading a monitor source is a pw-record-shaped stream away, and it is the precondition for transcribing anything that is not the user's own voice.

Echo cancellation. #248 was closed on the basis that Silero VAD handles this better now. VAD decides when to transcribe; it does not remove speaker output from the microphone signal, which is what module-echo-cancel does. If someone dictates while audio plays through speakers, VAD gates the segment correctly and the model still receives the mixed signal. I have not reproduced this carefully, so I am flagging it as a distinction rather than filing a regression.

Not urgent. I am filing it because the same hole exists on Windows (cpal, no WASAPI loopback) and macOS (AudioEngine.swift is AVAudioEngine microphone capture), which makes it a family-level limit rather than a Linux quirk.

Same gap on the sibling clients: VocaHQ/vocawin#38 (WASAPI loopback) and VocaHQ/vocamac#243 (Core Audio process taps).

[github-actions]

Thanks @kacperpaczos. A maintainer will look into it.

---

Meanwhile, connect with us:

[kacperpaczos]

Adding the use case I actually have, since I filed this saying it was not urgent. For me it is.

What I want is to start Vocalinux, record a conversation happening in some application, and get a transcript split by speaker. That is a different product from dictation and I am not proposing it be bolted onto the dictation loop. But it decomposes into four pieces, and three of them already exist somewhere in this org:

1. Capture — this issue, with two corrections below.
2. Long-form transcription — VocaGateway already does it: FFmpeg normalisation and several engines on a machine with a GPU. The dictation loop, with its 2 s silence_timeout, does not.
3. Speaker separation — nowhere in the org, but sherpa-onnx is an installed dependency of the gateway and upstream ships offline-speaker-diarization.py in its Python API examples, so the library is already present there and simply not called.
4. A document — archive, review, export. Does not exist anywhere.

Two things I got wrong or left out in the original report:

Lifting the filter gets you the system mix, not an application. _is_virtual_device() excludes monitors, so system output is one deny-list away for a mode where the user explicitly asks for it. Picking a single application's stream is a different job: PortAudio sees ALSA and Pulse devices, not PipeWire nodes, so "record this app" needs a native PipeWire client. Two very different amounts of work.

A conversation is naturally two tracks, and that helps. The monitor gives the remote participants; my own voice comes from the microphone. Recording both separately means "me versus them" is known by construction, and diarization is only needed inside the remote track — less work and better results than blind diarization of a mixed signal.