With no pipewire, "ESC Mixer Control" may fill up all pulseaudio connections in seconds and break sound for all apps

[ell1e]

Expected Behavior

even when pipewire becomes unavailable, ESC doesn't ever break pulseaudio sound as a result

Current Behavior

Sometimes "ESC Mixer Control" will fill up all pulseaudio connections in seconds and break sound for all apps. I think the trigger might be possibly related to pipewire being unavailable which admittedly then renders using the extension kind of moot (but a user might have installed it before that happening). But is still a situation that I suggest might be handled more gracefully. See here for logs!

Possible Solution

Steps to Reproduce (for bugs)

1. Install and enable EasyScreenCast extension, remove pipewire binary, make sure pulseaudio is available as alternative
2. (unsure what exactly then triggers it as additional condition)
3. ESC now hogs pulseaudio daemons and blocks use of it for anything

Logs

• Use journalctl /usr/bin/gnome-shell -f to monitor Gnome shell activity. Maybe the crash will log something.
• Log, enable verbose debug logs into options window, and after that try
  journalctl --since=today --no-pager | grep js
• webcam info:
  v4l2-ctl --all
• webcam info:
  for VIDEO_DEVICE in /dev/video* ; do echo ; echo ; echo $VIDEO_DEVICE ; echo ; v4l2-ctl --device=$VIDEO_DEVICE --list-inputs ; done
• webcam info:
  GST_DEBUG=v4l2src:5 gst-launch-1.0 v4l2src num-buffers=1 ! fakesink | grep probed

Your Environment

• Where did you download the extension?
  [x] Gnome shell extension website
  [ ] From Git (Add commit tag)

• Gnome shell version: 43.6

• Operating System and version: Fedora 37

• Display server: Wayland

[adangel]

One step further in the analysis:

• We create the mixer control here:

  EasyScreenCast/utilaudio.js

  Lines 65 to 75 in bb0139a

  	_createMixerControl() {
  	Lib.TalkativeLog('-#-mixer create');
  	// https://gitlab.gnome.org/GNOME/libgnome-volume-control
  	var _mixerTmp = new Gvc.MixerControl({
  	name: 'ESC Mixer Control',
  	});
  	_mixerTmp.open();
  	return _mixerTmp;
  	}

• We use it in the main extension here:

  EasyScreenCast/extension.js

  Line 73 in bb0139a

  this.CtrlAudio = new UtilAudio.MixerAudio();

  and

  EasyScreenCast/extension.js

  Lines 482 to 483 in bb0139a

  	// add menu item audio source from PA
  	var audioList = this.CtrlAudio.getListInputAudio();

  to populate the menu, where you can select the audio source
• We create the mixer/pulse audio client connection already, when the extension is enabled.
• However, when the extension is disabled, we don't remove the connection, e.g. the following destroy method is not called from anywhere:

  EasyScreenCast/utilaudio.js

  Lines 321 to 326 in bb0139a

  	destroy() {
  	if (this._mixerControl) {
  	this._mixerControl.close();
  	this._mixerControl = null;
  	}
  	}

• When the extension is enabled again, a new mixer is created. The old mixer is still connected.
• This happens everytime, the extension is enabled.
• The extension is disabled, when the screen is locked and enabled when the screen is unlocked.

I'm unsure yet, how this is connected with pipewire - and I'm hestitating to remove the pipewire binary... Maybe something has triggered so that the gnome shell extensions are enabled and disabled (maybe a crash?).

Note, that without pipewire, the whole extension is useless, as the screen recording is based on pipewire... No pipewire, no screen cast.

[ell1e]

For testing, it might be enough to just temporarily move/rename the binary, reboot and do all the testing, then move/rename it back, and reboot again.

Note, that without pipewire, the whole extension is useless, as the screen recording is based on pipewire... No pipewire, no screen cast.

I noticed, so I solved this by uninstalling it. But until I realized this was going on, it was a few months of breakage, so maybe it would be still useful to prevent this sort of malfunction.

[adangel]

Do you have any logs by any chance? It would be interesting, what gnome-shell logged...

[adangel]

Ok, so I tried this: in gnome-os you can't manipulate the filesystem (for once, /usr is read-only, but after reboot, it is restored). I had a ubuntu 22.04. When I rename /usr/bin/pipewire -> /usr/bin/pipewire.disabled and restart afterwards, nothing spectacular is happening. Screencast doesn't work anymore as expected (neither via gnome, nor via ESC), but I also didn't notice any additional pulse audio connections (checked with pactl list client | grep ESC). There is only one connection after login.

I suspect, something different happened on your machine. But without the original logs, we probably never know.

Since this is not reproducible, all I would fix for this issue is to cleanup the pulse audio connection properly, when the extension is disabled. Otherwise connections might accumulate, if you have a long running desktop session, which you just lock and unlock.

[ell1e]

I only have the logs I attached here, I moved to a distribution since that doesn't deploy pipewire for users yet (which I'm thankful for given how buggy it usually was for me) so the setup is now considerably different here