Screeching audio when using loopback

[Spam]

Hello and good day to everyone, and thanks for looking through this publication.
The situation is the following: I have a turntable that I like to plug in via USB to my laptop to listen/record. Everything was working fine until today, after working fine for like half an hour, a horrible screeching sound started being heard through. Naturally, the first thing I checked was the turntable, but nothing of the sort happens through speakers. So I tried also with the microphone, and yes, the screeching sound was still there, appearing semi-periodically.
My steps are the following:
Plug in the USB cable and enable loopback:

pactl load-module module-loopback latency_msec=1

I know this is broad, but what I am asking for is some guidance debugging, as this has started happening so suddenly and I can’t explain myself what could have changed in the same session (don’t worry, I also tried rebooting ).

Thanks a lot in advance, any advice would be greatly appreciated!

[OrsoBruno]

Looks like a buffer underrun / overrun somewhere in the sound chain.
I notice that snapshot 20250725 upgraded pipewire and snapshot 20250727 upgraded a bunch of gstreamer packages.
Are you still using pulseaudio or puleaudio on top of pipewire? If the latter you may run pw-top and watching the “ERR” column for errors showing up while you hear the effect.
You may also watch the “QUANT” column if it shows low values (less than 512 or 256) in the line(s) showing errors?

[Spam]

Yes, errors show up, QUANT on the line is 32

The Texas Instruments line is the turntable.

[oldcpu]

Some additional ideas …

It sounds like your openSUSE is experiencing an audio feedback loop or a sampling rate mismatch, which can definitely cause screeching sounds. Since both the turntable and a standard microphone exhibit the issue, it’s highly likely a software configuration problem on the laptop rather than a hardware issue with the input devices themselves. The fact that pactl load-module module-loopback is used further points to a potential loopback misconfiguration.

Some possibilities:

1. Audio Feedback Loop (have you changed turntable position relative to the laptop? ):
• Problem: The module-loopback command is designed to route input directly to output. If the input source (turntable or microphone) is picking up sound from the laptop speakers, it creates a vicious cycle of amplification, leading to a loud screech. This is especially common when speakers are too close to the microphone or the microphone’s gain is too high.

One idea to try to solve:
Disable Loopback for Testing: First and foremost, unload the loopback module:
ie try in a bash shell
pactl unload-module module-loopback
Then, try playing something from the turntable or speaking into the microphone. If the screeching stops, then the loopback was the culprit.

Use Headphones: The best way to use module-loopback for recording without feedback is to use headphones. This prevents the microphone from picking up the output audio.

Reduce Microphone/Input Gain: If using speakers, significantly reduce the input gain for the microphone or the turntable input in pavucontrol (PulseAudio Volume Control).
i.e Use pavucontrol (PulseAudio Volume Control):

• Open pavucontrol from your applications menu.
• Go to the “Input Devices” tab.
• While the turntable or microphone is connected and producing the screech, look at the input level meter. Is it maxing out?
• Try drastically reducing the input volume for the relevant device.
• Go to the “Output Devices” tab. Make sure the output volume isn’t set to an extreme level that could cause feedback.
• Physical Separation: Move the laptop’s speakers or the laptop itself further away from the turntable/microphone.

2. Incorrect Sample Rate/Buffer Size:

Problem: Another possibility, albeit much less likely (since this is a sudden onset), is a mismatch in sample rates between the audio input device (turntable’s USB audio interface or laptop’s built-in sound card) and PulseAudio, or incorrect buffer sizes. I read that these can lead to distorted or screeching audio.

An idea/approach to solve in this sample rate/buffer size speculation:
• Check the PulseAudio Configuration: I read the following on the internet. I have no idea as to whether it will work, as it is beyond my experience. But here it is and maybe take this with some skepticism:
◦ Open the PulseAudio configuration file (with your favourite editor, the example I saw suggests nano- which I never use myself): sudo nano /etc/pulse/daemon.conf
◦ Look for default-sample-rate and default-fragments / default-fragment-size-msec.
◦ Try commenting out default-sample-rate to let PulseAudio negotiate, or explicitly set it to a common value like 44100 or 48000.
◦ Experiment with default-fragments (e.g., 2 to 8) and default-fragment-size-msec (e.g., 5 to 25). Smaller values reduce latency but can cause crackling if too small.
◦ After making changes, restart PulseAudio: pulseaudio -k && pulseaudio --start
◦ Check ALSA Settings (Underlying Layer): Sometimes ALSA settings can influence this. You can use alsamixer in the terminal to check if any input levels are excessively high or if there’s a “Loopback Mixing” option enabled (though this is more for internal sound cards).

3. Corrupted PulseAudio/ALSA Configuration:
• Problem: Also very very remote, but possible, is that sometimes configuration files can become corrupted, leading to unexpected behavior.
• An approach to adopt if this is the case: I also read the following on the internet. I recommend caution before trying any of this as I would nominally be cautious in trying.
◦ Reset PulseAudio Configuration: You can try moving your PulseAudio user configuration directory to force a reset (where frankly I would not do such):
In a Bash shell try
mv ~/.config/pulse ~/.config/pulse_backup
pulseaudio -k && pulseaudio --start

This will create a new default configuration. If it fixes the issue, you can gradually reintroduce specific settings from your backup if needed. Again – myself? I probably would not do this unless totally desperate - as it could make thinks worse if one has previously spent time tuning their configuration.

4. Driver Issues/Kernel Modules:
• Problem: This is also very very unlikely for a “sudden onset” if nothing was updated, … but it is always possible that a recent kernel update or a problem with the audio drivers could be causing issues.
• Approach to investigate:
◦ Check Kernel Logs: Look for any audio-related errors in the system logs:
Bash
sudo journalctl -b | grep -i audio
sudo journalctl -b | grep -i pulse
sudo journalctl -b | grep -i alsa
◦ Reinstall Audio Packages: If you suspect package corruption, you could try reinstalling core audio packages (again – I read this on the internet but I likely would not do such unless totally desperate):
In a Bash shell:
sudo zypper refresh
sudo zypper install --force pulseaudio alsa-plugins alsa-utils

There is a lot of speculation in the above. Others may have far superior ideas as to what to consider.

[OrsoBruno]

Well, might be much simpler than that. I notice that you have Firefox running and there is a line titled “speech-dispatcher-dummy” that is linked to Firefox and can be disabled (I don’t recall how ATM but will research and come back).
It might be related to “Assistive technology”, sort of speech synthesis to readout loudly page contents. It caused similar issues here in the past.

EDIT: I think it is media.webspeech.synth.enabled that should be set to false in the about:config page. Of course if you don’t need such assistive feature.

[Spam]

It definetly is an issue with the loopback. I plugged in headphones, the screeching is there too. Really appreciate your input!

[OrsoBruno]

@Spam

pactl load-module module-loopback latency_msec=1

Confirming, just loading that module floods pipewire with errors.
Never used that module, so cannot elaborate further.

[Spam]

I just use it to be able to listen to what I am recording.

[OrsoBruno]

If you install helvum you will see a graph of what pipewire is doing. You should see a number of monitor_xxx outputs that you can “wire” to the input of loudspeakers or such (just click and drag output to input); if you find a suitable configuration there should be means to permanently configure that.

[OrsoBruno]

Try pw-loopback -l 1seems to work properly here, but might depend on your input and output configuration.

[oldcpu]

I note this flagged as the solution. Excellent !

This is interesting. I am trying to figure out why the ‘pactl load-module module-loopback’ command caused a screeching sound while ‘pw-loopback -l 1’ did not

I assume this is due to a difference in regards to an audio feedback loop.

The pactl command and PulseAudio

The command: pactl load-module module-loopback latency_msec=1 is a command for PulseAudio. My understanding is that it creates a software loopback, which takes audio from a source (like the OP’s turntable’s USB input) and sends it directly to a sink (the OP’s computer’s speakers or headphones).

But I think the low Latency Request (latency_msec=1) may become unachievable. While the low latency request sounds good in theory, I have read it may not always be physically possible for a typical consumer-grade sound card and the PulseAudio software stack to achieve this consistently.

So why the screeching? … again, based on what I read and not on my experience, in regard to pulse audio’s behavior: When PulseAudio can’t meet the requested latency, it may struggle, causing buffer underruns or overruns. This can lead to a highly distorted, glitchy sound that manifests as a screech or static. The system is essentially failing to process the audio fast enough, creating a chaotic and unpleasant output.

So that begs the question, why is PipeWire different?

I read that PipeWire is fundamentally a more modern and hoped to be more robust audio server designed to handle low-latency audio more effectively. It has a different internal architecture (with a “graph” of nodes) and a more sophisticated session manager (like WirePlumber). Purportedly it is better at negotiating and managing buffer sizes and latency.

So my speculation is that when the OP now runs pw-loopback, PipeWire gracefully falls back to a stable, achievable latency (maybe 10ms or 20ms) instead of trying and failing to meet an impossible 1ms target, thus avoiding the screech.

Mismatched Sample Rates

I also read a mismatch in sample rates between the OP’s turntable’s USB audio interface and the PulseAudio server can also cause severe audio distortion.

If the OP’s turntable outputs a 48000 Hz signal and PulseAudio is expecting 44100 Hz, the resampling process can be buggy, especially when combined with a low-latency request. This can lead to the screeching sound.

As for Pipewire? PipeWire purportedly is generally much better at handling and automatically managing different sample rates across devices, preventing these kinds of conflicts.

Summary: (based on my reading)

In summary, the pactl command with latency_msec=1 is a powerful but brittle command that can push PulseAudio to its limits. The most likely cause of the screeching, even with headphones, is that the system is unable to achieve the requested 1ms latency, leading to a software glitch or a digital feedback loop in the audio pipeline. The pw-loopback command, as part of the more modern and robust PipeWire ecosystem, is simply more resilient to these issues and is able to establish a stable and functional loopback connection.

If I have this assessment above incorrect (in regards to my efforts to understand why things do not work or why they work ) I would be most happy for others to add content/clarification. … I confess many times I feel that the move to pulse audio and then pipewire has left me behind technically, and I am very much struggling to catch up.

[OrsoBruno]

Your post looks like AI generated, so am I answering real questions? Anyway…
Here the pactl module works (well, sort of) down to latency_msec=2.
The pw-loopback works down to --latency 1 with some errors every now and then.
Down to those values there is no sign of defaulting to different latencies.
Since pa works through a dummy pulse audio server embedded in the pipewire system, the audio pipeline is longer when pa is in use, so some higher delay is to be expected.
Of course all that is hw-dependent so YMMV.
From post #3 above I see no rate mismatch between:

ID 97 (Burr-Brown from turntable)
ID 56 (alsa-output analog stereo)
ID 84 (loopback output)
ID 74 (loopback input)

all operating at 48000 Hz.

[oldcpu]

@OrsoBruno

Your post looks like AI generated, so am I answering real questions?

I don’t think i posted a question to anyone directly. Rather I posted what i am trying to learn.

To be clear, I don’t try to do what was done in order to attempt to record from a turntable. I don’t have that hardware.

But I am curious about audio. I tried surfing just on Google to understand why some aspects worked and others did not. It was time consuming, with minimal return. OK … ZERO useful return with Google. I will be honest.

so I used an AI bot to suggest why one command worked and one did not. It gave me an answer. I also tried the same in more than one AI bot as a ‘quality check’ . It helped tune an answer. I did not accept all of the reasons. Only the one’s that I thought, based in my limited time with GNU/Linux, as possibly being credible.

I believe that AI bot assistance, give me a FAR better idea as to what could be the reason.

As to whether it is the REAL reason? I don’t know for certain, but I definitely think it is better than 60 minutes or more of trolling through google with zero results. And I believe it 100% better than reading of a command and not attempting to understand.

What I posted is NOT, I repeat NOT pure AI bot output. Rather it is me reading the AI bot output, pondering it, and pasting what makes sense as being credible.

Is it thou, the real reason? I don’t know.

Again my view is it is better to try and learn, as opposed to blindly applying commands. Perhaps the reasons are more intuitively obvious to others, than they are to me. Fair enough. But I, for one, need the AI bot crutch at times, in order to learn more at a reasonable speed, with the full expectation, that 90% or more of my time needs to be spent verifying what the AI bot provides.

[oldcpu]

@OrsoBruno

Since pa works through a dummy pulse audio server embedded in the pipewire system, the audio pipeline is longer when pa is in use, so some higher delay is to be expected.

I found it interesting the way you stated pa working through a dummy pulse audio server embedded in the pipewire system. …

I spent some time after reading that in your post, reading a bit further on this. I previously understood that pipewire was coded in a way to work with pulse audio, but I did not take the time to dig much further on this …

… ie after reading the way you summarized this (which I now kind of like as a good summary) I did dig a bit deeper now, albeit not too much deeper.

What I read recently is in modern GNU/Linux systems, pipewire-pulse serves as a compatibility layer that allows the PipeWire multimedia server to act as a direct replacement for the older PulseAudio sound server.

I had not looked at this much before in the past, and I confess I did not (until now) appreciate that pipewire is a direct replacement for pulse audio …

I had a very wrong (not researched) fuzzy speculation before, that they both might work a bit in parallel. I have that sorted now.

To re-iterate … what I understand now is that pipewire-pulse serves as a compatibility layer that allows the PipeWire multimedia server to act as a direct replacement for the older PulseAudio sound server - which you succinctly summed up as a ‘dummy server’.

I read a bit further, and now have updated my knowledge to note that an application, such as a web browser or a game, which has in the past been designed to interface with the PulseAudio “language,” will still function, as pipewire-pulse intercepts these requests and translates them into PipeWire’s own language.

This seamless translation means that a large amount of existing software that was built for PulseAudio can run on a PipeWire-based system without any modifications.

Pipewire Intercepts the requests

Of course, one of the first things I asked, was how does pipewire intercept requests intended for pulse audio?

What I read was that when PipeWire is installed, for some (most ? ) GNU/Linux distributions, it replaces libpulse.so with a symlink to PipeWire’s own libpulse.so ( where pipewire-pulse in essence replaces the old libpulse library.). I believe this is the preferred method by most distributions.

I also read that alternatively, in some other GNU/Linux distributions (ie possibly Gentoo, Slackware, Debian (pre-bookworm) or Ubuntu (pre-22.04)), the system’s LD_PRELOAD or PulseAudio client library overrides ensure that apps use PipeWire’s implementation instead of a real PulseAudio server. To me that reads to be a more complex approach, but I am no programmer. Also, I am not certain re: those mentioned distributions which initially may have used this LD_PRELOAD method is still in use (nor maybe never used) the LD_PRELOAD method.

Further research, suggested that OpenSUSE (both Tumbleweed and Leap) primarily uses the library symlinking method to redirect PulseAudio applications to PipeWire, similar to Fedora and Arch Linux, and I speculate all distributions may be moving toward this simlink approach. Note ‘speculate’ is the operative word, as I still trying to learn more here. I could have this wrong.

ie. In a sense, if I understand this , due to this compatibility layer, the audio application believes it’s interfacing to a PulseAudio server, but it’s actually communicating with pipewire-pulse, which handles the audio routing, mixing, and device management behind the scenes using PipeWire’s more advanced, low-latency framework.

Hence this approach allows users to benefit from PipeWire, which I read has improvements, such as better support for some audio, video, and Bluetooth devices — while maintaining backward compatibility with all the familiar desktop applications that used pulse audio.

I am behind in my knowledge here. Other aspects have taken priority in my life, and I fell behind in my understanding of GNU/Linux in regards to pulse audio and pipewire … and I am hoping now to gradually catch up.

Back on topic …

This ‘screeching audio’ thread, is IMHO, a nice example for learning, in which one can consider some aspects of the changes with pipewire introduction as a direct replacement for pulse audio.
.

[OrsoBruno]

We are way OT here, but still… I think that there is only one person on the planet that truly understands pipewire: Wim Taymans of Red Hat
AIUI pipewire replaces PulseAudio, at least in openSUSE, in that when you install pipewire you have to uninstall pulseaudiobut you also get recommendation to install pipewire-pulseaudio which is a pulseaudio server implementation.
You can see it for instance via systemctl --user status pipewire-pulse if your system is running it.
So most general purpose apps (e.g. FireFox) still see and use that PulseAudio server, the difference being that instead of interfacing with ALSA like the “real” PulseAudio does, it channels the audio data through the pipewire pipeline.
Apps needing real-time sound interface directly with the pipewire sound processing and some, e.g. Audacity or the Deadbeef player, even offer options to use one interface or the other.
Bottom line, if you need PulseAudio it is still there but the extra processing adds some latency, delay and possibly minor impulse and frequency response distortions, as is apparently the case in this thread.
There is plenty of docs over at pipewire.org but frankly I only read what I needed to put my systems in good shape
Anyway, let’s show people that we are still learning after 25 YO