4 ms·
That's the approach I initially took, but experienced some combination of noticeable stuttering and latency regardless of which buffering strategy I tried... Ha
by eperot 3mo ago
That's the approach I initially took, but experienced some combination of noticeable stuttering and latency regardless of which buffering strategy I tried... Had to switch to a shared memory ring buffer, along with some adaptive playback speed shenanigans (sometimes imperceptibly speeding up playback when falling behind production of audio samples, sometimes imperceptibly slowing down when there's less than a few milliseconds' worth of samples left in the ringbuffer), in order to achieve actually-gapless playback.
- coppsilgold 3mo agoThere is something wrong with your setup. I just tried: bwrap ... --ro-bind /run/user/1000/pipewire-0 /run/user/1000/pipewire-0 ... -- runsc ... do ... -- mpv podcast.mp3 Flawless playback. I think it's a default pipewire configuration.
- eperot 3mo agoAh, I see the distinction. In my case, I was using the PulseAudio client+server with a network sink running in-sandbox, producing a set of audio samples that are then replayed by a PulseAudio client in the out-of-sandbox Rust application receiving these samples. Exposing the socket directly to the sandbox is dangerous, e.g. it would let the sandbox record the host's microphone directly. My goal was for the sandbox to only have access to a single dumb playback sink and no other access by default, and to gate any further access (e.g. microphone access) in something the out-of-sandbox software can catch and ask the user about before it is granted to the sandbox.
- coppsilgold 3mo ago> Exposing the socket directly to the sandbox is dangerous, e.g. it would let the sandbox record the host's microphone directly. libpipewire-module-pipe-tunnel also: <https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2874 https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_req...>