[Bug] Share screen with audio causes loud audio spikes for streamer

[different-name]

Discord Account

different_name

Operating System

NixOS

Linux Only ~ Desktop Environment

Hyprland

Package Type

Flatpak & nixpkgs

What happens when the bug or crash occurs?

When sharing screen with audio, me - the person screen sharing, will occasionally experience a very loud spike in volume for a split second. This only occurs when streaming with audio
I tried recording this through obs, but the audio spike does not occur in the recording

What is the expected behaviour?

Consistent system volume whilst streaming with audio

How do you recreate this bug or crash?

1. Start a stream with audio (entire system or application, doesn't matter)
2. Use computer normally, with sound playing

Debug Logs

Logs from starting vesktop to when the issue occured

$ flatpak run dev.vencord.Vesktop

Note that the directories 

'/var/lib/flatpak/exports/share'
'/home/different/.local/share/flatpak/exports/share'

are not in the search path set by the XDG_DATA_DIRS environment variable, so
applications installed by Flatpak may not appear on your desktop until the
session is restarted.

Using NVIDIA on Wayland, disabling gpu sandbox
Wayland socket is available, running natively on Wayland.
To disable, remove the --socket=wayland permission.
Passing the following arguments to Electron: --enable-speech-dispatcher --disable-gpu-sandbox --ozone-platform-hint=auto
[3:0720/210557.454761:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
APPIMAGE env is not defined, current application is not an AppImage
checkForUpdatesAndNotify called, downloadPromise is null
[3:0720/210557.695957:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[3:0720/210557.696011:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
(node:3) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open '/home/different/.var/app/dev.vencord.Vesktop/config/vesktop/settings/quickCss.css'
    at async open (node:internal/fs/promises:636:25)
(Use `vesktop.bin --trace-warnings ...` to show where the warning was created)
(node:3) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
{ discordBranch: 'stable', minimizeToTray: 'on' }
[3:0720/210630.162870:ERROR:shared_x_display.cc(39)] Unable to open display
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
[2024-07-20 21:06:32.400] [venmic] [info] [patchbay] (handle) found default metadata: 41
[2024-07-20 21:06:32.401] [venmic] [info] [patchbay] (meta_update) speaker name: "alsa_output.usb-TC-Helicon_GoXLR-00.HiFi__Speaker__sink"
[2024-07-20 21:06:32.401] [venmic] [info] [patchbay] (get) running venmic 6.1.0
[2024-07-20 21:06:37.029] [venmic] [info] [patchbay] (create_mic) created: 152
[3:0720/210637.058050:ERROR:shared_x_display.cc(39)] Unable to open display
[3:0720/210637.102114:ERROR:shared_x_display.cc(39)] Unable to open display

Request Agreement

• I have searched the existing issues and found no similar issue
• I am using the latest Vesktop and Vencord versions
• This issue occurs on an official release (not just the AUR or Nix packages)

[different-name]

I use the nixpkgs day to day, did a fresh install of the flakpak today for this issue and same result. I did not import or configure any vesktop settings on the flatpak, I only signed in and started a stream. So I don't think this is configuration related

[kotudemo]

I have the same issue on Windows

[kekkodance]

same

[dotaxis]

I have been wondering for a long time what was causing these audio spikes and didn't realize it was only happening while I was streaming. I even bought a new DAC because I thought that was the culprit.

How bizarre.

Arch btw, using the vesktop-git AUR package.

[dweee]

Across Windows and NixOS too.

[megumann]

Across Windows and NixOS too.

I can confirm that this is occurring on Windows systems as well. Those who watch the stream report being able to hear audio system-wide instead of isolated to the application when streaming a specific window.

[different-name]

Tried this on Windows today, more like the audio stutters than the spikes I got on NixOS. Very different sound

[a-usr]

I have been experiencing similar behaviour as described, and I also found that Vesktop wrongly connected to the output of a Pipewire Input node. Removing that connection using qpwgraph solved the audio Issues for me.

[Curve]

and I also found that Vesktop wrongly connected to the output of a Pipewire Input node.

What version of venmic / vesktop (+ venmic settings) are you using? There are explicit checks in venmic that prevent this.

Please attach a log if applicable (see the venmic repo on how to enable debug logging)

[a-usr]

Venmic version: 3.4.2
Vesktop version:

stable 326854 (2e9e66d) Build Override: N/A
Vencord f27361f (Vesktop v1.5.2)
Electron 31.4.0
Chromium 126.0.6478.234

The nodes in qpwgraph (PRO Mono is the mic):

venmic log

not sure what you mean with venmic settings or where I can find them

[Curve]

Venmic version: 3.4.2
Vesktop version:

stable 326854 (2e9e66d) Build Override: N/A
Vencord f27361f (Vesktop v1.5.2)
Electron 31.4.0
Chromium 126.0.6478.234

The nodes in qpwgraph (PRO Mono is the mic):

venmic log

not sure what you mean with venmic settings or where I can find them

The problematic node in this case is the Titanfall one?

The Venmic settings are the audio share settings shown when starting a screen share.

[a-usr]

The problematic node in this case is the Titanfall one?

Yes, to be specific its the Titanfall 2 [audio stream #1] node. In the game it is used for voice chat.

The Venmic settings are the audio share settings shown when starting a screen share.

Ah. Apart from setting the audio source to Titanfall 2 instead of the entire system I dont change anything. I'd also like to add that the issue only occurs if I do that, when venmic listens to the entire system it doesn't connect to that listen node.

Also sorry for taking so long 😬

[Curve]

The problematic node in this case is the Titanfall one?

Yes, to be specific its the Titanfall 2 [audio stream #1] node. In the game it is used for voice chat.

The Venmic settings are the audio share settings shown when starting a screen share.

Ah. Apart from setting the audio source to Titanfall 2 instead of the entire system I dont change anything. I'd also like to add that the issue only occurs if I do that, when venmic listens to the entire system it doesn't connect to that listen node.

Also sorry for taking so long 😬

Thanks for the info, seems like the Titanfall node does not have the proper media class, which is why that happens.

This should be an easy fix, I will probably issue an update by the end of the week.

Are you on the vencord discord by any chance?
If so, would you be willing to test the fix before I issue a release? (Ping me in the vesktop-development channel, name is the same as on GitHub) That would help a lot ^^

[a-usr]

Are you on the vencord discord by any chance? If so, would you be willing to test the fix before I issue a release? (Ping me in the vesktop-development channel, name is the same as on GitHub) That would help a lot ^^

Not right now, since I'm at work atm, but if I remember when I get home sure!

[PaulRicharte]

Can confirm the issue on Fedora 41 as well. I'm willing to test any patch if wanted!

[megumann]

Across Windows and NixOS too.

I can confirm that this is occurring on Windows systems as well. Those who watch the stream report being able to hear audio system-wide instead of isolated to the application when streaming a specific window.

Since this post I can confirm this issue is present on Arch Linux; both using X11 and Wayland on Pipewire. It occurs typically when starting a stream, and at random during it. I also note that sharing the entirety of the display will sometimes produce stuttering.

In my experience on Arch, I have been using a GNOME desktop. This issue existed in GNOME 46 and persists into GNOME 47, which helps to solidify the likelihood that this is an audio/video processing issue and not a desktop issue.

Issues occur on Windows specifically when using the Vesktop client. I don't think this is an issue with Linux A/V processing, and more with Vesktop's method.