Linux screen share audio stutters and distorts with large PipeWire buffers

Observed behaviour

I've tested on both the official canary server and self hosted desktop client (I compiled it myself and just updated Constants.ts on fluxer_desktop to point to my server) , and to make matters weirder, screenshare on the person's side that recorded my screen works absolutely fine, we have the same exact systems (Kubuntu 26.04) The issues are random, sometimes audio skips/stutters, sometimes out of sync/sped up, and sometimes sync is fine and no stutters but it sounds like the speakers are busted. The app also randomly decides whether HEVC is available or not, sometimes it only works if I disable-restart/enable-restart hardware acceleration, but just in case I tested screensharing on both situations and the result is the same (both official canary and my own host). I spent hours trying to pinpoint the issue to no avail so I'm trully sorry I can't give better details. Screen record on OBS by my friend: 643091456-fddd6233-ebe5-4c6a-91b6-0c205fe2c1eb.mp4

Reproduction steps

Download the canary appimage
Log in to any server
Start screenshare with audio (doesn't matter if entire system or only firefox)

Build information

Canary Desktop 2026.828.171905, Web 2026.829.14014, Linux 7.0.0-30-generic (x64), Electron 42.10.0, Chrome 148.0.7778.280, Node 24.18.1, Locale en-US

Platform

macOS, Windows, Linux

Evidence

I've dropped the evidence on the observed behavior.

5 comments

RexSystem 1 vote 1mo ago originally by @wagnerfs on GitHub OP

I digged through a bit more and done plenty of tests, I tried recording the output from pipewire directly from the fluxer node and the audio is fine, so I narrowed it down to how fluxer is probably dealing with encoding. I've added a dump function on https://github.com/fluxerapp/fluxer/blob/baa18aed5b2a28cb199d38abca151cc0b68e960b/fluxer_desktop/src/main/NativeAudio.ts#L772 right before the audio is sent and the audio is already bad there. out.mp3 For comparison, the video I was sharing: https://www.youtube.com/watch?v=dxqZ3fBxclU I'll backtrack from there to see what else I can find.

out.mp3 1.2 MB

Found the culprit: https://github.com/fluxerapp/fluxer/blob/baa18aed5b2a28cb199d38abca151cc0b68e960b/fluxer_desktop/native/linux-audio-capture/src/pipewire/stream_ops.rs#L277 Is hardcapped to one MAX_FRAME_SAMPLES pass. I set my clock.min-quantum to 1024 to prevent some audio crackles due to small buffers, this directly affects: https://github.com/fluxerapp/fluxer/blob/baa18aed5b2a28cb199d38abca151cc0b68e960b/fluxer_desktop/native/linux-audio-capture/src/pipewire/stream_ops.rs#L292 Which does a single pass of the truncated at 1920 payalod and silently drops the rest. I've updated both functions locally to decode f32 samples passing an offset as parameter to be able to decode everything until the end of the payload or until scratch is full, then loop through the entire payload until the payload is fully drained instead of a single pass. This completely fixed the audio quality issues I had.

HampusStaff 1 vote 1mo ago originally by @hampus-fluxer on GitHub

Thanks! Would you like to submit a PR for this? I sent you an invite for collaborator in case you do.

RexSystem 1 vote 1mo ago edited originally by @wagnerfs on GitHub OP

@hampus-fluxer sure can do, I'm not well versed in rust though, I'm a C++ dev, so I had a LOT of reading to do what I did so I'll need a rougher review on that. Anywhere I should look into for PR guideliness too? (couldn't find any)

HampusStaff 1 vote 1mo ago edited by moderator originally by @hampus-fluxer on GitHub

@wagnerfs Cool! All you need to do for the pull request is to fill out the template which is inputted automatically by GitHub, noting that it closes this issue and write a short answer to each section according to the comments. It doesn't require a lot of effort, just a sentence for each is enough! What you've written in the comment above is enough information, you've proven it works for you :)