#discordscreenaudio — 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

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

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

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

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

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

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

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

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