Microphone Feeds Back to Output

[jaakkopasanen]

I have an issue where using PulseEffects makes me hear my microphone through my headphones. This happens after I use Google Meet or Zoom video conference and close the conference call. Doesn't happen if I don't start PulseEffects.

Running Ubuntu 18.04, pulseaudio 12.2-2 and PulseEffects 4.7.1-1~bionic1

[wwmm]

It feels like third party tools are messing with our audio routing again :/. Kill PulseEffects pulseeffects -q and restart it in debug mode G_MESSAGES_DEBUG=pulseeffects pulseeffects. After that start these applications. If we are luck our logs will show something useful. But my guess is that something external to PulseEffects is moving our playback pipeline input from our virtual sink monitor to your microphone. If that is that case Pavucontrol recording tab will reflect this change after these conference call is closed.

[beanaroo]

I can confirm the Microsoft Teams desktop client is doing something here. It was driving me nuts and after not finding any other reports, I started playing with PulseEffects.

Toggling the "Skype" application off and on, seems to temporarily fix it.

Will try to capture some logs

[wwmm]

Also pay attention to any change in Pavucontrol recording tab. Our playback pipeline should always be recording from PulseEffects(apps) monitor. This is hardcoded in PE. So if our stream is recording from somewhere else an external tool asked Pulseaudio to change its input device.

[wwmm]

In the same way the stream responsible for microphone effects should always be playing to the sink PulseEffects(mic) and recording from your microphone.

[Haywire-dev]

I am having a similar issue, when I try to record my screen (with tools like OBS Studio, Kazam, SimpleRecorder) with my default Audio Output there is only the sound of my microphone getting captured. Any idea of what can be done to fix this? I'm not using Skype. The closest from Microsoft I got is VSCode, which shouldn't mess with audio.

I'm on Debian Bullseye (unstable), using PulseEffects 4.7.1.

[wwmm]

But I am almost 100% sure that something is asking Pulseaudio to change our playback stream input device

[Haywire-dev]

Is there anyway to debug that or see any interaction? After a reboot I have Discord, OBS Studio, PulseEffects, Firefox, Hyper (Terminal) currently in use, if it can help.

[wwmm]

There is one. Try to follow the advanced section in our wiki link https://github.com/wwmm/pulseeffects/wiki/Reporting-Bugs. Only looking at Pulseaudio's logs we will be able to find out who is moving our stream to the mic. But this log may be big. Save it to a file and attach it here.

[wwmm]

Are any of you using GNOME settings to change the default input device? GNOME settings is known to mess with custom audio routing.

[Haywire-dev]

Here is what I managed to get while following the Wiki instructions, hopefully it will be enough.

Specs:

• PulseAudio 13
• PulseEffects 4.7.1
• Debian Bullseye (Unstable)

Steps achieved:

• Started journalctl with PulseEffects closed.
• Started PulseEffects
• Started a music on a music player (that's the python app), music works fine
• Started OBS Studio, audio output spectrum is moving only according to the microphone.

PulseaudioLogs.txt

Edit: I specifically never touch to the "default" audio manager on Cinammon as I've read that it can cause issue with the audio routing of PulseEffects.

[wwmm]

Are you sure the log is complete? It shows the python audio player but stops before showing anything related to OBS.

[Haywire-dev]

Do I have to try and record a video with OBS Studio? I only checked the audio output spectrum preview and saw it was only responding to the microphone, so that might be why there is no mention of OBS. I am gonna try a new log in an hour, after a reboot and I will launch OBS + a recording after executing journalctl

[wwmm]

In principle it should not be necessary as the the problem happended. But somehow Pulseaudio's logs show nothing about this input device change in our stream. Very unusual.

[Haywire-dev]

Just in case, it doesn't take a lot of time and I want to make sure to provide as much info as I can.

Steps:

• Rebooted computer
• Started journalctl then PulseEffects
• Started a python music player, played a song (might have went forward and rewinded a bit to test)
• Started OBS Studio, recorded a small video with only Audio Output
• Only the microphone is captured by the video, not the music player

PulseaudioLogs_v2.txt

Another test with the same steps. I have a doubt if I launched PulseEffects on the v2 logs or not, so just to be sure, I've redo all the steps. PulseaudioLogs_v3.txt

[wwmm]

Oh! I think that now I understand what you want to do. Your case may be different from the ones above. It is not that you have a problem. You are facing a limitation. You want to record both the mic and the app in OBS. But in other to apply effects to the mic PulseEffects makes OBS to record from the sink PulseEffects(mic) monitor. And the audio effects applied to the music player are being played to the sink PulseEffects(apps).

Unless that a more complex setup based on loop back devices solves this situation I think you will have to choose which app has effects applied. The music player or the microphone.

[wwmm]

If you do not want effects applied to your microphone just disable Process All Inputs in PulseEffects settings menu. When you restart OBS PulseEffects should not touch it anymore. If that is not enough also disable OBS the switch shown in PulseEffects window(the one for mic plugins) that Pulseaudio will forget this association.

[Haywire-dev]

Oooh that's actually very true I see, well I wasn't trying to record both, I just needed to record the Audio Output, and disabling Process All Inputs solved the issue, now the Audio Output is properly recorded...

Sorry for my misunderstanding about the situation, and thank you for pointing out a solution!

[jaakkopasanen]

This happened couple of times again. I checked the Pulseaudio volume control recording tab and indeed the source stream for PulseEffects had changed to my physical audio interface. Selecting Monitor of PulseEffects fixes the problem.

Unfortunately I don't know how to reproduce the problem so it's hard to debug it. When this happens I'm usually in a conference call so there's no time to start figuring it out at that moment either. I'll try to remember to start PulseEffects in a debug mode from now on and hopefully we'll get some more info soon.

[wwmm]

I played a little with the Google Meet test in its configuration menu but there were no problems. Maybe we have to be in a real call. Does its test function trigger the problem in your computer?

[NikSays]

Happens to me too. Just opening sound tab in Gnome settings changes PulseEffects recording source to Built-in Audio Analog Stereo. Does not happen when PulseAudio Volume Control or OBS is open

[wwmm]

@NikSays in this case it is Gnome's fault. Pulseaudio 14 will even come with an workaround to forbid Gnome Sound Settings of messing with audio routings.

[jaakkopasanen]

Looks like the problems are related to Gnome sound settings. Switching input devices will set recording stream for PulseEffects to the new input device. This has been a problem for me because I have two USB audio devices with inputs: Logitech C920 webcam and Behringer UMC202HD audio interface. After booting to Ubuntu the C920 is always the default input device so I have to switch to the audio interface to use my mic. Usually I only remember to do this when in conference call and I actually need to use my mic. If PulseEffects is already open, the recording stream will change to the audio interface input and I'll start hearing my mic. Now that I'm aware of the problem I can simply switch the PulseEffects recording stream back to "Monitor of PulseEffects(apps)" and it's all good. Selecting the input device before starting PulseEffects also prevents this from happening.

Another somewhat related problem is with output devices. If I start PulseEffects first and then open Gnome sound settings, the default output device is still going to be the physical output audio device instead of "PulseEffects(apps)". When I select PulseEffects(apps), output goes silent. This can be solved by selecting a different output device in PulseEffects Pulseaudio settings and switching back to the correct one. So seems like Gnome sound settings messes up the routing for this as well.

Am I supposed to have the physical audio device as default output device or PulseEffects(apps) in Gnome sound settings?

I took a quick glance at the Pulseaudio 14 notes and looks like that might fix both of these problems.

[wwmm]

@jaakkopasanen never set PulseEffects(apps) or PulseEffects(mic) as default output device. Always set you hardware as default. In an ideal world our virtual sinks wouldn't even be visible to the user. But as far as I know there is no way to do that in Pulseaudio :-(

This Gnome "feature" is very annoying. Fortunately Pulseaudio 14 will have a workaround to force it to be disabled. Until that I suggest you use Pavucontrol to manage devices.

[jaakkopasanen]

Thanks for clarification. As far as I'm concerned, this ticket can be closed.

[alexivkin]

I don't like commenting on the closed tickets, but I hit the same exact issue on Kubuntu with PA12 and no gnome. All audio is handled via plasmashell and systemsettings plugins. On reboot I get the PE microphone sink routed to the source. As soon as I start an app that asks for a mic, for example Chrome with Google Meet tab open, I get a massive echo feedback through the speakers. Turning off Chrome input processing in pulseeffects solves it, but, of course I lose all effects on the mic input. I can resolve it by killing PA and restarting PE, which seem to get the sink-source situation in order, and get the mic effects on Chrome.

[wwmm]

@alexivkin feel free to open a new issue. If you do that please add logs by killing the current PE instance pulseeffects -q and restarting it in debug mode G_MESSAGES_DEBUG=pulseeffects pulseeffects. Try to reproduce the problem while getting the logs.

Either kde is automatically loading some kind of loopback device that is causing the echo or it is messing with audio routing in a way that causes it. In these cases we usually have to take a look at Pulseaudio logs to see who is changing routing. You can do that by following the advanced section in our wiki https://github.com/wwmm/pulseeffects/wiki/Reporting-Bugs

[alexivkin]

Thanks. Before I submit the ticket thought, how does pulseeffect loading sequence is supposed to happen? This issue happens on boot and on resume from sleep with a usb mic. Does it go "udev creates sound device -> PA module-udev-detect creates alsa-card -> PA sets up default routing -> pulseeffect creates the virtual source/sink on load sets its own routing there? And how does pulseeffect daemon start on systemd systems with no gnome? Is it waiting for pulseaudio to finish setting up its stuff? Might there be a run condition on boot/resume when PE starts before PA is finished? This would help me troubleshoot the root cause before sending the ticket.

[wwmm]

PulseEffects is a gui application that requires that both Pulseaudio and a graphical login are already running. Our service isn't really a service. I used a GTK feature that allows a graphical app to run with its window hidden. This made my life a lot easier as implementing a proper service would probably require dbus and a quite elaborate communication between client and service.

Think of PulseEffects as an audio recording app. The only difference is that we move the apps to which effects are applied to a null sink we create. When PE starts it expects to find a functional Pulseaudio. We do not touch udev or systemd. Low level stuff is done by Pulseaudio.

At least on my desktop resuming after suspending causes no issue. But things may be different on other configurations. But in the event that PE starts before Pulseaudio I would expect a crash or silence. I don't see how an echo could happen as PE won't run if Pulseaudio is not already running.

[ShayBox]

Based on the comments in this issue, this is what I've been experiencing, and it turns out that even if you select the PulseEffects (app) monitor for the desktop audio in obs, it always uses the PulseEffects (mic), unless you disable input processing, the temporary solution is to open pavucontrol or any other method of changing it back, which only works temporarily.