#discord-screenaudio — Public Fediverse posts

This #discord-screenaudio bug is still ongoing over a month later. It's a blessing however because I've discovered another custom #Discord client on #Linux that is FAR better than this one and I've been very happily using it for a month now called, #Vesktop.

Vesktop too is a Discord client that brings screensharing with audio on Linux, with some important differences with discord-screenaudio (DS, for short) with my use case:

- When streaming, besides allowing you to choose from which application it should share audio from, it also allows you to choose which application it should share video of. DS only supports the former, and only shares the entire screen which is not only not ideal for privacy but bad for performance. +1 also for Vesktop for making the UI/UX pretty much exactly the same as the native Discord client on #Windows so users familiar with this feature should feel right at home.

- Vesktop is just more reliable, at least when you have more than 1 capture device. I've 2 capture devices - 1 for my mirrorless camera used as a webcam, and another for capturing my #SteamDeck and #NintendoSwitch to my PC. On DS, my camera feed would not default to my actual camera (it defaults to the Deck/Switch capture card instead) and there's no way to switch between them easily as you would on the native client WITHOUT doing a little dance (detach and reattach my capture card). On Vesktop, it behaves exactly as it would on the native client and it defaults to my actual camera properly, and I can also switch between the capture cards very easily.

- DS has extremely limited configuration options, a lot of settings found in the native client such as hardware acceleration are not available to be enabled/disabled. Vesktop has all this covered, again, like the native client.

TLDR; All in all, for your streaming with audio on Discord needs on Linux, please use Vesktop. Because of these reasons, Vesktop is not only usable for me for streaming alone - but I'm perfectly able to use it as a complete replacement to the native Linux Discord client. It is widely available through #Flathub as a #Flatpak, and it should also be available natively on your distro (#AUR for #ArchLinux).

🔗 https://github.com/Vencord/Vesktop

🔗 https://flathub.org/apps/dev.vencord.Vesktop

RE: https://sakurajima.social/notes/9plczf5h3a

Weird bug going on the custom #Discord client on #Linux, #discord-screenaudio. I use it to be able to stream their screen, with audio, and that still works fine - but for some reason I could not see any cameras/screens on the client including my own - it's just pitch black apart from the UI elements on the client.

🔗 https://github.com/maltejur/discord-screenaudio/issues/225

Update 1.9.2 is out for #discord-screenaudio on #Flatpak and the issue has been fixed!

RE: https://firefish.social/notes/9lbzb7cqq9etqy8d

There's an issue since yesterday with the #discord-screenaudio application becoming unusable. Any action such as entering a voice channel and so on would return this error message. This is an unofficial #Discord client #Linux folks can use to easily stream/share your screen with audio (which is not yet supported on the official Discord client on Linux).

No update is out yet to fix this, but fortunately a PR fixing this was already up almost immediately yesterday. Hopefully it will get merged and the update that pushes this to be released soon after. Until then, if you rely on this app to stream things to watch together with your partner/friends like me, you can make do by using Discord's "Activities" and watch something on #YouTube together instead.

🔗 https://github.com/maltejur/discord-screenaudio/pull/200

this issue still occurs across reboots. it's one of those issues that will happen, but once i manage to somehow "work around it", it's fine - until a reboot. the weirdest #Linux #bug i've encountered for sure.

the previous update of mine saying that it was fixed by removing one of my capture card then reconnecting it wasn't reliable, and likely not the cause - as the issue does still happen without the logs i mentioned.

the only thing i've pinpointed which is reliably indicated every time the issue happens is that upon checking #ksysguard (system/activity monitor), the highest CPU usage would be #wireplumber - which i assume has to do with #pipewire or something.

this time, i managed to "work around it" (no confirmation yet) by just restarting pipewire.service. the issue also did start this time when i was using the custom #discord client (#discord-screenaudio) to stream audio from #firefox/#plex. but it's happened before with the official #discord client too, and something else entirely.

RE: https://firefish.social/notes/9igswqeuc1wodmr2

still have no idea what the hell's causing this #bug on #Linux, but I do know that it also happens sometimes when sharing screen on the official #Discord client. I usually only stream using #discord-screenaudio (shortform: DS) though, and when say, I open up #Plex and DS, Plex just wouldn't be able to load any of my content up and when it does, it's really slow and there's no audio.

same thing when the issue occurs, everything else from that point forward such as opening up a #YouTube video on #Firefox, will be extremely slow to load and has no audio. If i just restart my PC and do any of this all over again, it'll just work as it did before. fuckin annoying.

I suspect it has something to do with #Pipewire, but I've no idea since I've not had any issue this bad/serious before. this is all happening on #EndeavourOS (#ArchLinux), #KDE #PlasmaDesktop, on #X11 running an #NVIDIA GPU + #AMD CPU. Kinda curious if it would also occur running on #Wayland but using Wayland on this machine has been a buggier mess in the past.

i'll live w this shitty buggy behaviour for as long as i'm able to i guess at this point. journalctl logs are filled with gibberish crap to be helpful in any way.

UPDATE:

checking journalctl and dmesg, i did get a bunch of logs such as these:

[58042.550376] usb 4-1: reset SuperSpeed USB device number 2 using xhci_hcd
[58042.934322] usb 4-1.2: reset SuperSpeed USB device number 5 using xhci_hcd

this has been the buggiest period since my migration to #Linux yet - for some reason. i couldn’t even have the entire desktop not freeze/bug on me with gray, unresponsive, empty windows when opening the share screen portal on #discord-screenaudio. i’m getting that issue where windows/notifications just appear in complete black too which has been around since forever on Linux/#KDE #PlasmaDesktop as far as I know but it’s happening to me so frequently now when it’s very rare before. no idea tf is happening to be causing all this.

this has been the buggiest period since my migration to #Linux yet - for some reason. i couldn’t even have the entire desktop not freeze/bug on me with gray, unresponsive, empty windows when opening the share screen portal on #discord-screenaudio. i’m getting that issue where windows/notifications just appear in complete black too which has been around since forever on Linux/#KDE #PlasmaDesktop as far as I know but it’s happening to me so frequently now when it’s very rare before. no idea tf is happening to be causing all this.