linuxmemes

Most of psyops are done via memes nowadays

I have not worked on human rated launch vehicles, but I've been adjacent to them, saw what went into them, and a few close personal friends have worked it.

Anything that can jeapordize the safety of the crew must go through a rigorous independent validation and verification process that takes years, software included. No shot a Microsoft product was even in consideration for those systems.

Being in industry I find it crazy that so many people are freaked out by this. Astronauts have email, they have tasks and schedules and reports to make. Why would NASA reinvent the wheel on a task/schedule manager when the ground operators and astronauts are already used to using Outlook.

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

@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

Eh, I aliased it to rpipe because it is short for "Restart Pipewire", so I won't forget it.

Eh.

I change my audio output device a lot and my wired USB headset confuses the hell out of pipewire, especially if I have the microphone unplugged/hardware muted.

I just restart pipewire until it breaks again, which is most likely after a system update/restart anyways.

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.

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.