Maybe it's time to give it a shot again. Does pipewire have similar functionality to voicemeeter the virtual audio cables?

And the awful thing is when you're the only one having this specific issue. I'm the "bad audio" guy, another is the "VPN never works", etc...

I don't know what you mean. I can just hit the print screen key on my keyboard and have a screenshot in my clipboard.

My pipewire seems to have issues with crackling audio and severely dampening my mic and I have no clue why.

Pipewire's default quantum (buffer size, effectively) is incredibly low, this is good for low latency audio but anytime your system is too busy to keep the buffers filled you get crackling.

If you look at pw-top you'll see all of your devices and nodes. The quant column is probably 1 or a very small number for the devices.

You can increase the quantum with this command. This only lasts until pipewire restarts:

 pw-metadata -n settings 0 clock.min-quantum 512

At a sample rate of 48000, this is roughly a 10ms buffer. 1024 is 20ms, etc. You want it as low as possible without getting crackling. Start with 512 and adjust from there (you don't have to use a power of 2, a quantum of 1234 works just as well).

severely dampening my mic and I have no clue why.

By default pipewire doesn't do any 'mic boost', as Windows calls it. You can get the same effect by raising the maximum volume.

In your sound control panel you should be able to turn the mic up higher than 100%. In KDE Plasma, you can do this in System Settings -> Sound -> Configure Volume Controls... [top right button] -> Raise maximum volume.

Alternatively, you can use EasyEffects to add a compressor. This will boost your mic volume and also prevent it from getting too loud

Compressors basically reduce the dynamic range of an audio signal by attenuating loud sounds and boosting quieter ones, this would provide a better mix.

Other useful plug-ins are noise canceling, (kills background noise) and echo canceling (lets you play sound out of your speakers which won't get picked up by your mic). Sometimes apps, like Discord, will do this signal processing for you while others, like Signal, do no signal processing.

That's not a pipewire problem, that's a systemctl problem.

Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

The error means systemctl --user can't reach your user's D-Bus session because the required environment variables aren't set. This typically happens when you've switched users via su or sudo rather than logging in directly, because htose don't initialize a full systemd/PAM session. It could also be that your session wasn't properly initialized by systemd-logind or a number of other things.
Try spawning a proper user session:

sudo machinectl shell your_username@

and try the systemctl command again.

You're in the right place, most social media users can't properly formulate their thoughts into sentences, lol.

everything

New tip just dropped

Read the arch wiki on troubleshooting pulse audio. I remember having this issue long ago.

I used to have crackling issues with pulseaudio. It needed restarting constantly. Not issue since the switch to pipewire. So my experienced was the absolute opposite of yours.

The issue occurred yesterday gaming with friends and I didn't have time to troubleshoot yet, but I'll keep that in mind, thanks!

Nope, wired. Separate ports for input / output on the front of the case.

Oh I had this issue and it drove me bonkers trying to fix it! I have to go digging a not to try and remember what fixed it in the end.

I need it to automate fishing in Minecraft, and the normal way to take screenshots in Python (which is one line with PIL) on Linux went from at least 30 possible fps on X11 to 2 on Wayland. The only way to do it fast enough then is to use Pipewire. Which is one hell of a convoluted mess. (The next part of this whole mess will be finding a way to send mouse clicks without having Minecraft registering a mouse move too in case xdotools stop working)

Its not real its referring to the issues they had with outlook

You need the print screen key for something else is what you're saying (I had trouble following your reply)?

Can only speak for KDE, but you can easily change the screenshot shortcut to something else in settings.

I feel this one. Used to daily drive Linux but due to a work requirement had to switch to Windows several years back. Windows has been getting shittier and shittier and I no longer need to use Windows for work and it only just gets shittier so I just switched to CachyOS and love it. Except the one and only issue I haven't been able to fix is audio. I use a Bluetooth speaker on my computer and it cuts out randomly even using low bit rate audio streams. Tried switching pulseaudio to pipewire because the internet said I could increase the latency and that that would fix it but no dice.

Some Mediatek chips are doing this, that is bt audio cutting out while WiFi doing things. Nothing fancy, 1080p video on YouTube will cause that.

Never used it, but I use something called pipewire graph or something (I'm on vacation and I can't be bothered sorry heh)

They don’t have the same goals.

JACK is for professional audio.

OSS and ALSA are kernel audio drivers, they’re the most powerful of them all but extremely low level. Everything else, like pulseaudio/pipewire are just higher-level interfaces that feed ALSA audio.

Pulseaudio and pipewire are sound servers.

So really it only took two tries:

OSS -> ALSA

Pulseaudio -> Pipewire

There's helvum and carla control that allow you to edit the entire audio graph with all ins and outs for all hardware and software so you can route it however you like. No need for VAC and such. But even if you do, you can load pulseaudio modules i.e. pactl load-module module-null-sink and then route them with qjackctl which is absolutely crazy and awesome how pipewire lets you do that.

Hm? Removed pulse, installed pipewire-pulse, ran pipewire && wireplumber && pipewire-pulse as user and everything just works. Except that my cheap bt-inear sometimes cause a crash of bluetoothd (and that one should restart by itself but whatever) but that's not pipewire's fault.

Every OS has audio issues. Even TempleOS.

alias rpipe='systemctl --user restart pipewire'

My Mint laptop audio stopped working for a couple months and then miraculously fixed itself this week. I made various attempts to fix it with no luck. It’s either a hardware issue or some obscure software issue.

In the past, I had plugged in a HDMI cable to mirror the screen and couldn’t get the audio working again until I plugged it back into HDMI and switched it back to the internal speakers before unplugging HDMI. Before the audio broke this time, I had connected a USB microphone, so it’s possible that’s what did it.

I'm writing a script that automatically take screenshots of the desktop (in particular the Minecraft game window) and then use OpenCV to do template matching to recognize if I've caught a fish or not.

If I use any usual screenshot capabilities of any python library, I simply cannot take pictures fast enough (at least 10 images per second) to have the script work (under Wayland the usual system top out at 2 images per second).

The only way fast enough I've found so far is to use Pipewire to create a livestream of the desktop and get frames of it to do the job.

And it is a complex mess. (At least I've found a (very basic and badly documented) library to do most of the work instead of having to work it all through Dbus myself.)

It's just that what once was a single line in my previous X11 script is now a full on script by itself, and I understand almost nothing of it.

Happened to me on Mint as well. Never resolved it. Using Nobara and Fedora now and never had any audio issues. Seems to be something with how Mint handles audio as I see people mention this a lot.

my body is a TempleOS

@MonkderVierte @tjhrulz Hm? Removed pulse, installed pipewire-pulse, run pipewire && wireplumber && pipewire-pulse as user and got no available sound devices.Why? Because wireplumber's bullshit crashed after forking to daemon somewhere in camera support code (but i do not have cameras!).With reference pipewire-media-session everything worked, but everybody forcing unstable and bloaty wireplumber, making old configuration not supported...Yes, maybe it's not pipewire fault, just it's modular architecture, but it makes me unhappy with it, so i still using jack. And i sure, there should be separate provider processes for camera and audio devices

Well that one is pretty obvious isn't it? Consoles and the like have a single target hardware, or very few at least, so their testing is way more reliable. Meanwhile a random PC will have one of several hundred chip designs, implemented by a few dozen different vendors, ranging over decades. Development for and testing under such conditions is just way more complicated, so all devs can really do is aiming for #worksonmymachine and hope for detailed bug reports and feedback when others have issues.

Give Ubuntu Studio a try maybe? It comes with a lot of audio production stuff preinstalled and preconfigured, one of the most important ones in this context being low-latency process scheduling.

Essentially most distros just have default process scheduling options, which means a process might be starved for CPU time, theoretically for up to 2s or so at a time, which is very bad if that process is generating or consuming an audio stream. Low-latency scheduling, while not entirely preventing it from happening, should significantly reduce this.

You could also just configure most other distros Kernels to do low-latency scheduling of course. Or if you don't want to muck about with kernel settings try Ubuntu Studio, which has that and more all ready to use.

Sorry @luciferofastora@feddit.org, I got out of bed and completely forgot to actually go check what I did. My issue was under high load the audio would crackle, I could never quite establish if it was GPU or CPU, but at least it was during intenser moments in games. I played around a lot with the quantization that people in here have already suggested but it never fixed the crackling.

What finally solved it for me was to enable threadirqs. You can do this with sudo kernelstub -a threadirqs. I don't entirely understand it, but I believe it makes the interrupted handler execute in threads.

Interesting, I’ve only ever had this issue in Mint as well.

Anyone have any idea how to troubleshoot my motherboard's HD Audio device just not showing up at all in my hardware devices? I've made sure it's enabled in UEFI settings but it just appears to not even be enumerated by the hardware scan.

My previous mobo's HD Audio also didn't show up at first, but that one fixed itself by the time I came around to troubleshoot it (maybe an update?). Had to replace that mobo because of hardware damage, but I didn't bother reinstalling the OS as I didn't think it was necessary.

Other then hoping the next round of updates resolves this, I'm out of ideas.

I also had audio issues with windows in the past,
But to be fair, it was a driver issue and it fixed itself when I updated it,
It still was random.

But on a serious note, mine just jumps up and down in volume randomly

it got really hard to use pulse

Pulse was another tumour by Lennart. I have no regrets in its passing.

typically happens when you’ve switched users via su or sudo rather than logging in directly,

1. I wish typical scenarios were the only ones we had -- it'd be a trivial solution.
2. This is a largely unmolested install because I don't want to be debugging my desktop. If I had a point other than whingeing, here, that would be it: when the default, vanilla, least-tuned setup falls over on the regular, then it's fundamentally a failure at its "you had one job" task.

If you're using, Debian, Mint, or Ubuntu try updating the kernel to the most recent version

I feel it...can't get rid of audio crackling in 3.5mm jack on my Acer nitro for ages...

My laptop is Mint and it's never given me audio issues. My gaming rig is Nobara and the only audio issue I've had with it is that I forgot to switch the output to the TV.

This is psyop, they run windows up there, their outlook doesn't work, and everyone kinda accepted that.

This is a meme, sir.

Just life, linux just works with audio

I absolutely wasn't expecting a helpful response under a meme, so thank you very much for taking the time to write it!

anytime your system is too busy to keep the buffers filled you get crackling

I'd have to test that more thoroughly, but I do think that lines up with the timing of the issues.

You can increase the quantum with this command. This only lasts until pipewire restarts:

Can I put that in some config to make it stick?

I'm admittedly very junior to pipewire config, so most of what I have is copied from the internet, tweaked for node names / descriptions, but I generally like working with config files and slowly learning what all that stuff in there means.

I have two loopbacks (I like having music and games each grouped separately from other audio), an echo-cancel and a noise cancel (filter-chain with a single rnnoise node), all configured via .conf files. As an aside, is there a "best order" to chain echo cancel and noise cancel?

Echo cancel seems to have a quantum/rate of 480/48000 across the board. Loopbacks, rnnoise and alsa_output (my headset) all have 0/0. I imagine it makes sense for the Loopbacks and rnnoise, but should it be something else for the main output?

By default pipewire doesn't do any 'mic boost', as Windows calls it. You can get the same effect by raising the maximum volume.

Well, it seemed to work just fine without echo cancel, if I capture the mic directly, but putting it through echo cancel (with or without noise cancel) seems to reduce the gain significantly.

I'm gonna mess with the volume sliders and see which ones I can crank up to fix that issue.

But I'm confused why that issue would occur in the first place and if I have something misconfigured.

Alternatively, you can use EasyEffects to add a compressor. This will boost your mic volume and also prevent it from getting too loud

Sounds like a compressor would be a good idea to have anyway. Is that also doable through the config? I'm not opposed to graphical tools, I just feel like working with the config directly is more educational. It's also more prone to screwing things up, but that's just bonus lessons on what not to do.

Sometimes apps, like Discord, will do this signal processing for you

Curiously, the reason I looked at echo-cancel in the first place is that Discord's own echo fucks with things, cutting me out at times while also not cancelling the echo at others.

Thanks for remembering, checking and getting back to me! I'll look into that threadirqs thing, thanks for the pointer!

Are you running dsp operations of some sort?

They're just like me! I have no idea which I'm using either.