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.

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.

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

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.

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