Darn I tried

Well, a large audio buffer size for music is basically irrelevant and for VLC or MPV playing video, I think that they look at the buffer size to compensate for audio/video sync, and can have their buffer size increased (for mpv, it's --pipewire-buffer=<milliseconds>).

But that's not gonna fix it for everything, and you'd rather not have games breaking up either, I'd imagine.

Let's see...what can measure scheduling latency...

If you install the linux-perf package (well...that's what it's called in Debian...looks like it might be just perf in Bazzite) then you'll have the perf command.

If you run:

$ sudo perf sched record -- sleep 5

That'll sit there for 5 seconds and record all of the times a process was waiting to run and how long it took.

Then you can view that with:

$ sudo perf sched latency

You'll get something like:

 -------------------------------------------------------------------------------------------------------------------------------------------
  Task                  |   Runtime ms  |  Count   | Avg delay ms    | Max delay ms    | Max delay start           | Max delay end          |
 -------------------------------------------------------------------------------------------------------------------------------------------
  NetworkManager:1771   |      0.102 ms |        1 | avg:   0.038 ms | max:   0.038 ms | max start: 851647.533266 s | max end: 851647.533304 s
  systemd:1             |      0.167 ms |        1 | avg:   0.030 ms | max:   0.030 ms | max start: 851643.615504 s | max end: 851643.615534 s
  kworker/u129:1-:1923454 |      0.087 ms |        4 | avg:   0.030 ms | max:   0.035 ms | max start: 851647.788477 s | max end: 851647.788511 s
  TaskCon~ller #0:1921660 |      0.039 ms |        1 | avg:   0.027 ms | max:   0.027 ms | max start: 851644.615405 s | max end: 851644.615432 s
  wpa_supplicant:1773   |      0.052 ms |        1 | avg:   0.027 ms | max:   0.027 ms | max start: 851643.959252 s | max end: 851643.959278 s
  Netlink Monitor:1894113 |      0.082 ms |        2 | avg:   0.025 ms | max:   0.030 ms | max start: 851647.532516 s | max end: 851647.532546 s
  kworker/14:0-mm:1907945 |      0.015 ms |        1 | avg:   0.025 ms | max:   0.025 ms | max start: 851646.508509 s | max end: 851646.508534 s
  rtkit-daemon:(2)      |      0.060 ms |        2 | avg:   0.024 ms | max:   0.031 ms | max start: 851645.848483 s | max end: 851645.848514 s

That should give you a way to measure how long it's actually taking for a process to run once it wants to (the "Max delay ms" column). The buffer length is gonna need to cover that. Lemme go find something that'll give some idea of what kernel code is actually running...couple utilities that should do that. If it's some driver using a lot of time, might give a hint as to what kernel code is running.

looks

Ah, okay.

$ sudo perf record -ga

Until you kill it with Control-C, it'll sample and record what's running in perf.data. Then:

$ sudo perf report

And you can expand individual categories with "+".

I can't say "look at X, and that's it", but if something's running in the kernel, it should show up there. If it's, say, something with "nvidia" or similar in its name, that could be a hint that it's your video driver.

EDIT: Also, OP, I hate to bail on you, but I have to get some household chores done that I can't put off any longer, so I'm going to have to disappear for now...

I have read through the article and I am 99% sure it's schedule issue

after dozens of seconds without load I get this output:

sudo cyclictest --mlockall --smp --priority=80 --interval=200 --distance=0             
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 4.86 7.85 6.59 6/2385 19280             

T: 0 (17848) P:80 I:200 C:2016327 Min:      3 Act:   29 Avg:   16 Max:    3939
T: 1 (17849) P:80 I:200 C:2016322 Min:      3 Act:   25 Avg:   15 Max:    3910
T: 2 (17850) P:80 I:200 C:2015361 Min:      4 Act:   32 Avg:   16 Max:    4195
T: 3 (17851) P:80 I:200 C:2016059 Min:      4 Act:   26 Avg:   16 Max:    4057
T: 4 (17852) P:80 I:200 C:2016323 Min:      3 Act:   31 Avg:   15 Max:     495
T: 5 (17853) P:80 I:200 C:2016278 Min:      4 Act:   23 Avg:   16 Max:    4686
T: 6 (17854) P:80 I:200 C:2016153 Min:      4 Act:   23 Avg:   16 Max:    4259
T: 7 (17855) P:80 I:200 C:2016166 Min:      4 Act:   28 Avg:   18 Max:    3922
T: 8 (17856) P:80 I:200 C:2015946 Min:      4 Act:   28 Avg:   16 Max:    3724
T: 9 (17857) P:80 I:200 C:2015942 Min:      3 Act:   40 Avg:   16 Max:    4621
T:10 (17858) P:80 I:200 C:2015718 Min:      3 Act:   29 Avg:   17 Max:    3520
T:11 (17859) P:80 I:200 C:2015339 Min:      4 Act:   26 Avg:   16 Max:    2046

tested default.clock.rate with 44100 and 48000 it still crackles,

#default.clock.allowed-rates is commented out

closing easyeffects helped with VLC, but it still crackles occasionally in MPV and frequently in spotify

journalctl has no messages generated when crackling.

edit: reading through the pw-top article and it might give me clue

I would suggest trying to lower the sample rate to something like 44.1 or 48khz which is already CD/DAT quality, higher sample rates are good for recording and dedicated playback but just day to day it's a bit overkill honestly, and unless you have high grade equipment (AD/DA converters, monitor speakers or headphones, etc.) it's not really that noticeable, worth a shot anyways

Also in the docs it says that the default.clock.allowed-rates is not enabled by default anymore because of problems with kernels and bluetooth so you might want to remove the rate from those brackets

Note that this is not enabled by default for now because of various kernel and Bluetooth issues

when running stress-ng --timeout 30s --cpu 12 it still happens so it's not RAM issue

Memory: 12.05 GiB / 13.49 GiB (89%)
Swap: 16.62 GiB / 35.59 GiB (47%)

I would bet that this is more a matter of memory and I/O usage than CPU usage. It looks like you don't have a lot of headroom, and Blender and games will also use a lot of memory.

You could test this hypothesis by running a command that will cause high CPU usage but very little memory or I/O, like this: python3 -c 'while True: x=1'

You're looking in the right places.

You're getting buffer underruns

the software isn't able to fill the buffer fast enough to keep up with the sound hardware; that's what causes crackling.

I believe that the ERR column is a count of underruns (it certainly includes those; dunno if anything else can cause that). I haven't looked at B/Q before, though apparently that can also be useful in diagnosing load. The outputs are getting underruns.

It looks like you've got some sort of software equalizer in use there, easyeffects. I'd probably try flipping it off and seeing whether your crackling disappears. I haven't used it, but it looks like there's a way to flip it off for a given output. I'm also assuming that the easyeffects stuff attached to your mic means that you're running a bunch of software effects on your microphone (reverb, equalizer, etc).

I don't know how to read the pw-top output off-the-cuff to know the "chain" of audio there, or how to attribute a particular "cause" in a chain, but the fact that there are large ERR numbers for easyeffects does look suspicious.

If easyeffects is your culprit, then if you don't care about using it, you could just disable it entirely. If you do, I suppose that things to look at:

• Whether it's possible to increase the priority of whatever process is running easyeffects. I'm not familiar with how it runs, whether it's a stand-alone process or what, but if it is, maybe try renice -n -19 pid-of-easyeffects-process, which will temporarily give it maximum non-realtime priority.

• Whether you want to increase the quantum. It looks like some of that is running at a sample rate of 192000. The buffer is the quantum divided by the sample rate, so a quantum of 2048 (the smallest I see on what I think is the hardware) is about 10 milliseconds. Your floor of 32 in that config file isn't going to affect it. You can temporarily increase the quantum with pw-metadata -n settings 0 clock.force-quantum 4096 where 4096 is the new quantum. I don't know if that affects running streams or not

might need to re-open the program playing the music, but you can look in pw-top to see if QUANT goes up when you run the command. If increasing that quantum further addresses the issue, that'd be a data point. Note that this will cause audio delay from a game or such, so cranking it higher than it needs to be isn't ideal.

• It might be that some driver is taking up a lot of time. So, I'd think that a modern system could normally handle a buffer of 10 milliseconds, but that a driver for some piece of hardware is blocking things for an excessive period of time

I've seen that when, for example, loading models into VRAM on a Radeon video card for AI computation, things can get jittery. Sometimes the kernel will print messages when a driver is blocking things for too long; sudo journalctl -krb might be printing messages, be something to glance at.

If by install AUR inside distrobox, you mean run a distrobox that has access to the AUR? Then, yeah, you'd need the Arch container for distrobox and either install pamac or yay

Syncthing with a push/pull across devices and multiple databases is amazing. I have a master db, a db of Netflix or similar that I can share freely with friends that can sync things back over, so that we can share accounts without fussing about changing passwords since it all syncs over quickly.

• Emacs is one of my primary tools. It's not just an editor, it has many use-cases and micro-applications within. But it's very hard and long-winded to get into. Not recommended for just checking it out. You need to be certain that that's a tool you want to use long-term.
• pass is a simple but amazing CLI-based password manager. It requires a gpg key pair (because it uses gpg for en-/decryption), which is a tool that's notoriously hard to get into, but once you've got that, pass is amazing, especially when paired with the script passmenu + the tool wofi/dmenu, as you'll have insanely fast access to any stored password on hotkey press.
• syncthing is a great way to sync files across devices (serverless, you just need a discovery host (self-hosted or public) for your devices to find each other over the internet). Easy to use.
• Some (usually rust-based) coreutils alternatives like exa (ls), bat (cat), fd (find), procs (ps) are nicer to use than the "originals"
• ripgrep (rg) - MUCH faster than grep. Recommendation: use smart case (meaning that if you type your search term in lower case, it searches case-insensitively (which is usually what you want), but as soon as you include at least 1 cap, it searches case-sensitively, which is smart)
• ripgrep-all (rga) - allows you to full-text-search through "everything" (including some binary formats like PDFs, Office documents, zips, ...). Insanely fast as well.
• ledger - is a plain-text accounting software for tracking and introspecting your finances or expenses in plain-text form (also has a great Emacs package/integration from the same author)
• fzf - can be combined with other tools or scripts to allow fuzzy-searching through various result lists. Here's a neat example from my bash aliases ("pi" stands for "package install", name it whatever) which you can use on an Arch-based distribution to have a fast fuzzy-search mini TUI package installer, it's just cool:

pi() { printf '\e[1;37m[pacman] \e[1;32mInstall new packages (TAB to select, ENTER to install)\e[0m'; pacman -Sl | awk '{print $2($4=="" ? "" : " *")}' | fzf --multi --reverse --info=inline --height='80%' --color='hl:148,hl+:154,pointer:032,marker:010,bg+:237,gutter:008' --prompt='> ' --pointer='▶' --marker='✓' --bind='?:toggle-preview' --bind='ctrl-a:select-all' --preview='pacman -Si {1}' | xargs -ro sudo pacman -S --needed; }

thanks, i can already click the tray icon to enable and disable, but really liked the convenience of the automatic disabling via the brightness and gamma applet until it stopped working.

Debian (stable) is my vote for reliability. Always has been. The only time Debian might not "just work" is when you have VERY new hardware (new on the market) and need the absolute newest kernel version to have the necessary drivers. In such cases, look at Fedora, Mint or Kubuntu.

No, it's a compositor effect. You could write a simple wrapper script to disable before launching, and re-enable after closing though.

Thanks for the notice, the .ml were seen suspicious to me earlier, especially when I saw the last thing I was supposed to write in the ancet field or whatever it was called

It's advisable to generally avoid .ml comms because they're authoritarians (see below) in addition they'll ban for simply mentioning "ricing", not sure why, think they view it as anti-China or something

But for what you ask

!unixporn@programming.dev

!unixporn@lemmy.sdf.org

Okay thanks

There's multiples, all with a similar name, on lemmy. While that's not what you asked for here, those communities are likely to have people that can answer you better and faster

!unixporn@lemmy.ml

!unixporn@lemmy.world

And

!unixporn@programming.dev

nice chart! and thanks for the dark version

https://secureblue.dev/contributing#ai-content

In the interest of accuracy, quality, and license of the project, contributing using AI generated code and content of any kind is forbidden.

No linux distro advertises as "AI-free" because that's a bit like saying a burger is uranium-free

Likely because at this point, it's an almost impossible standard to hold for an open source project.

"AI code" is a very vague term. What if somebody used an LLM autocomplete in their IDE? What if they used an LLM to summarize and parse documentation, but wrote all the code themself? What if they generated the initial code with an LLM, but then heavily modified and tuned it by hand? What if they wrote the initial code by hand, but used an LLM to debug or optimize it? What if they wrote all the code by themself, but used an LLM to write unit tests and modify documentation?

If you're against every single example I gave, that's fine, but many if not most of these would be nearly impossible to tell if somebody had done it. Project maintainers are already spread extremely thin without also having to be AI detectives. Many/most large projects have already banned AI slop contributions, but that only stops the most obvious and lowest quality vibe coders and agentic bot spam.

The truth is that a large portion of devs are using LLMs in the kinds of ways I described earlier, right, wrong, or otherwise. Some distros are leaning into the hype, others are just quietly doing their own thing.

If you want to steer clear of explicit AI inclusion, I would just stick with distros that aren't bragging about implimenting those kinds of features. Check their main project page, check their official blog if they have one, look at the lead maintainers' github/lab pages and projects and see if they are big into AI stuff or not.

At this point, that's probably the best you can do.

I'm happy with Debian, yes.

You may be interested in the deliberations Debian has had earlier this year on exactly what should be permitted or banned with regard to contributions generated by bots.

Nonsense. There are at least half a dozen of us! I missed the large community part.