Pulseshitter streams the microphone when the process closes its sink

[LyesSaadi]

Hello !

We have that annoying issue with games which closes their audio sink when using pulseshitter, either by closing the game or because the game itself just stops playing sounds and closes its sink when it does. When those games do that, pulseshitter begins to stream the microphone's audio creating annoyance for everyone in voice chat.

Although, I've noticed that this is sometimes inconsistent ? I don't know exactly what triggers that, but, if pulseshitter could avoid switching to the microphone, or could try to only capture audio from a single process, and just not stream anything when this process closes its sink, and restreams it when that process reopens a sink, that would be great !

Examples to try to reproduce this are Firefox or the Henry Stickmin Collection.

The process also appears in yellow when that happens for some reason.

[Enitoni]

Pulseshitter has a mechanism in place to kill the stream as soon as the sink input is closed, because it is actually not pulseshitter changing to the microphone, but parec (the process recording your game). This is an issue with the original pulsecord (that this project was inspired by), that pulseshitter is supposed to fix.

This is not an issue me or my friend can reproduce. Can you give me some steps to reproduce the issue? It shouldn't be happening. Also tell me what audio devices you have, and the version of pulseaudio/pipewire on your system.

The yellow process means that the sink input is closed/gone. pulseshitter displays it in yellow and allows you to still select it so that once it comes back, it can continue the stream. This is to fix issues where for example seeking in a video or muting and unmuting will cause the sink input to change.

[Emik03]

Works fine for me on both Firefox and Henry Stickmin Collection, I suspect you have an outdated version of pipewire, or perhaps some quirk with pulseaudio?

What distro do you use? I have never run into this issue on popOS 22.04 or Fedora 38, both on pipewire.

It should look like this when you have closed the sink input that is currently streaming.

[LyesSaadi]

Hi ! This is weird, then...

So, I'm on Fedora Silverblue 39, so, prolly not a pipewire version issue.

❯ pipewire --version
pipewire
Compiled with libpipewire 0.3.80
Linked with libpipewire 0.3.80

Can you give me some steps to reproduce the issue?

There isn't any difficult process to reproduce it from my side, really. I just finished playing with friends henry stickmin, and the issue is triggered after a few seconds without any sound from the game, but it could also be just the game closing the sink at that time.

Maybe some quirks with Silverblue ?

[LyesSaadi]

So, a bit more testing, so, it's actually properly seeing that the sink is closed. The UI just "defocuses" all entries, but pulseshitter outputs my sound.

Here are some steps I did on Firefox:

• A video that was playing, but is paused (the sink is displayed).
• I click the entry, it is correctly waiting for audio without outputting anything.
• I replay the video, Firefox seems to close the old sink (?), what I selected defocuses in the UI, and pulseshitter outputs my voice.

Test 2:

• A video which was currently playing.
• I click the entry, it is correctly playing the video's audio.
• When stopping the audio, no issue.
• But when, replaying, it defocuses on the UI, and plays the microphone's sound.

With any other game I played, when I closed the game, it would begin to output my voice.

[Enitoni]

Just to be sure, you're on the latest version of pulseshitter, correct?

If that is the case, can you run this command and tell me what you get? pactl --version

I also checked with my friend, and they are on pipewire 0.3.83 not 0.3.80 so it's possible this is a Fedora regression. If possible, can you try upgrading to that version and see if that works?

Your steps to reproduce do not seem to work. pulseshitter stops outputting when the sink is closed as intended. So this has to be caused by a difference in your system and ours.

[Enitoni]

This is the line that determines whether or not to clear the stream (aka, stop it). This assumes that the device stays the same, and that the stream has not moved (for example, to your microphone).

https://github.com/Enitoni/pulseshitter/blob/06670f9beee363f052cc5011413fb92b7ca82dc4/src/audio/parec.rs#L65

My suspicion so far is that you have a version of pipewire that does not properly send this event.

[LyesSaadi]

I think I was on the latest pulseshitter, recompiled it just to be sure, and it didn't change anything.

For pactl :

❯ pactl --version
pactl 16.1
Compilé avec libpulse 16.1.0
Lié avec libpulse 16.1.0

I'll try to rebase to the testing repos of Fedora 39 for latest pipewire, as updates is currently in a freeze.

[LyesSaadi]

Tested with 0.3.83, it doesn't solve the problem :/...

[Enitoni]

That is very strange. Could you try running the parec command that pulseshitter runs and see if it detects the sink input closing properly? It should start with "Stream moved to" and is outputted to stderr. Show me the logs of what that looks like after you have reproduced the issue. Just be sure to direct stdout to /dev/null as it will spam your console with raw audio if not.

https://github.com/Enitoni/pulseshitter/blob/06670f9beee363f052cc5011413fb92b7ca82dc4/src/audio/parec.rs#L74-L91

[LyesSaadi]

How to get the device and source ids ?

[LyesSaadi]

Okay, so tried to do it manually with Helvum:

• Opened parec
• Removed the automatic links to the microphone : first tip, there is no message when doing that
• Added a link from Firefox : there's a stream moved message
• Removed the Firefox links, either manually or automatically when the sink closes : no message

Ouverture d’un flux enregistrement avec une spécification d’échantillon « s16le 2ch 44100Hz » et un plan des canaux « front-left,front-right ».
Connexion établie.
Création du flux réussie.
Mesures du tampon : maxlength=4194304, fragsize=352800
Utilisation de la spécification d’échantillon « s16le 2ch 44100Hz », plan des canaux « front-left,front-right ».
Connecté au périphérique alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_6__source (index : 52, suspendu : no).
Flux déplacé vers le périphérique Firefox (344, non suspendu).
^CSignal obtenu, fermeture.ce : 1788757 µsec.        

"Flux Déplacé" means Stream moved. That message appeared only when first connecting Firefox to parec at step 3, but not when closing the connection at step 4.

[Enitoni]

You can get the commands from here:

https://github.com/Enitoni/pulseshitter/blob/06670f9beee363f052cc5011413fb92b7ca82dc4/src/audio/pulse.rs#L633-L649

[Enitoni]

I think I see the issue already. Your output is in french. pulseshitter cannot properly detect the events if the output is in french. There might be an environment variable you can run to get it to output in english.

[LyesSaadi]

Oh that would be hilarious if that's the issue.

[Enitoni]

Try running pulseshitter with this environment variable: LANG=C

[LyesSaadi]

Yup, that was the issue :laughing: ! This is hilarious.

[Enitoni]

I'll hopefully get around to updating pulseshitter later (currently don't have my setup) so I'll commit a fix by then. In the meantime, you'll have to run the binary with that environment variable.

[LyesSaadi]

Seems like a pretty trivial fix for me, and I have a setup ready, will try to send a pull request your way !

[Enitoni]

Sure, go for it!