If it's in the Arch or CachyOS repos, it should be perfectly fine. The Arch packages are maintained by trusted devs, and unless the CachyOS team has been backdooring all their optimized builds this entire time with nobody noticing, they seem to be trustworthy, too.

Generally, if you can get it via pacman, you shouldn't have to worry.

That said, it sounds like you would want password autofill and easy adding. For that, don't bother with the desktop app and just use the extension in your browser of choice. There's no autofill via the desktop app.

are you talking like the bitwarden-cli? yeah that's in the arch repos. other than that you'd just install the extension on whatever browser you use.

or you could just use the official browser extension or just the web app

I'm not great at reading pkgbuild but It looks safe to me. It all looks pretty legit.

The ver-bump is alluded to in the comment section for the package. It all looks legit, a tiny bit weird, but not malicious.

In the future, if you're finding yourself suspicious. Just go upstream. Nobody says you have to use the package supplied from the AUR. Compilation from upstream is a skill, but a simple one. The compiler will tell you exactly the problem if things won't build (it's usually missing dependencies).

As much as I hate them, I had to use claude/chatgpt to piece this together last week since I'm not a developer.

I've been using it since but none of my AUR packages have actually needed to be updated so it may not actually be working as intended.

Basically it's a wrapper for yay that has a built in 7 day delay for updating an aur package. It will flag them so you can see what needs to update, and you can force it through with a --force flag if you're sure. Since all of the attacks that have happened in recent memory have been discovered within a couple of days I figured this is the easiest way to not get caught up in it.

If it does do what I want I'm hoping to never have to touch it again.

https://github.com/CMDRHorn/yay-safe

At least, until you’re genuinely confident in your ability to assess PKGBUILDs.

This has always been ArchLinux' requirement for using the AUR.

You don't need so-called AI to figure that out.

1. look at PKGBUILD - I see nothing untoward. The SKIP for checksums is normal for -git packages. No weird dependencies.
2. look at the source. https://git.ffmpeg.org/rtmpdump - that's the official ffmpeg site, and their git repo. And I see nothing untoward there, either: https://git.ffmpeg.org/gitweb/rtmpdump.git/shortlog

Fam, with all due respect, perhaps consider to not rely on the AUR at all for the time being. At least, until you're genuinely confident in your ability to assess PKGBUILDs.

If you don't have internet, which you may need for some of the fixes mentioned here, you can try tethering, which is where you share a phone's internet with a computer over a wired connection.

https://wiki.archlinux.org/title/Android_tethering

https://wiki.archlinux.org/title/IPhone_tethering

Although, these might depend on NetworkManager, although they might not.

Oof,

sudo apt install --reinstall network-manager

Thats what I'd do instead of recrafting the service or whatever. Kubuntu ships with network manager so it seems broken to me but maybe someone who actually uses Kubuntu can be more insightful.

Edit: wait I am dumb, you can't get to the internet huh?

If you can't get to the internet, at least grep for the package

dpkg -l | grep network-manager

to see if it didnt get nuked somehow. If it prints to the console its there.

Then you need to check the services in etc/systemd/system/ for one called NetworkManager. Its probably not there.

I get an error:

Failed to enable unit: Unit NetworkManager.service does not exist

sudo systemctl enable NetworkManager

In a terminal should just add it to start up when the service is enabled.

I was doing rumours, yeah. I watched wildmudkip do uim and seeing someone like him not enjoying it made me never touch the game mode lol. I'm also too much of a digital hoarder :^I

Also, are you a fellow uim enjoyer? I can see various item charges not related to RC 😅

Edit: or are you doing rumors?

Same thing happened to me after my toddler niece smashed all the keys on the keyboard.
Try hitting "Ctrl" and "-" at the same time to zoom out on your desktop like you do on a browser. Or try different similar combinations like "Alt".

Not familiar with that DE, but it xould be triggered by super+scroll or three-finger zoom

Jiggleflex integrity fix pl0x

magnifier is really bad for RC xp and I'd like to revert this asap!

I figured out how to fix it...

System settings > accessibility > zoom & magnifier > disabled.....

I still would like to know how accidentally mashing the bottom left of my keyboard caused it to magnify in the first place...

I don't see Gentoo.

I have ruled out the RAM issue by running as simplified test as possible: spotify + stress-ng and easy effects not running

free -h
               total        used        free      shared  buff/cache   available
Mem:            13Gi       7,8Gi       851Mi       166Mi       5,9Gi       5,7Gi
Swap:           35Gi       2,3Gi        33Gi

iostat
Linux 7.1.3-ogc3.4.fc44.x86_64 (bazzite)        17.07.2026      _x86_64_        (12 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,04    0,01    2,64    0,11    0,00   87,20

Device             tps    kB_read/s    kB_wrtn/s    kB_dscd/s    kB_read    kB_wrtn    kB_dscd
nvme0n1           0,03         0,67         0,00         0,00      11939          0          0
nvme1n1         108,97      1720,07      2211,60      2309,40   30620304   39370413   41111372
zram0           145,99       105,04       478,97         0,00    1869980    8526568          0

I have started to dig more into the perf, trace-cmd and cyclictest and finally managed to run all of the in the same time to capture the same high delay event. If the arch forum is correct then pipewire uses data-loop.0 process for realtime processing. It got SCHED_RR, so it seems correct as according to man pages it would preempt the SCHED_OTHER that stress-ng runs in.

Interesting thing I (and a council of clankers) noticed in trace_cpu_4.txt is that the interrupt didn't fire at specified time, and when it did, scheduler immediately preempted stress-ng to run the cyclictest as it's SHED_FIFO.

My current theory is some sort interrupt problem

trace-cmd report > trace.txt sed -n '2682652,2684299p' trace.txt > trace_extract.txt cat trace_extract.txt | grep -i "\[004\]" > trace_cpu_4.txt

logs:

ps -eo pid,class,rtprio,ni,pri,comm -L | grep -i 'rr\|ff\|dln'
     19 FF      99   - 139 migration/0
     21 FF      50   -  90 idle_inject/0
     24 FF      50   -  90 idle_inject/2
     25 FF      99   - 139 migration/2
     30 FF      50   -  90 idle_inject/4
     31 FF      99   - 139 migration/4
     36 FF      50   -  90 idle_inject/6
     37 FF      99   - 139 migration/6
     42 FF      50   -  90 idle_inject/8
     43 FF      99   - 139 migration/8
     48 FF      50   -  90 idle_inject/10
     49 FF      99   - 139 migration/10
     54 FF      50   -  90 idle_inject/1
     55 FF      99   - 139 migration/1
     60 FF      50   -  90 idle_inject/3
     61 FF      99   - 139 migration/3
     66 FF      50   -  90 idle_inject/5
     67 FF      99   - 139 migration/5
     72 FF      50   -  90 idle_inject/7
     73 FF      99   - 139 migration/7
     78 FF      50   -  90 idle_inject/9
     79 FF      99   - 139 migration/9
     84 FF      50   -  90 idle_inject/11
     85 FF      99   - 139 migration/11
    104 FF      50   -  90 irq/9-acpi
    108 TS       - -20  39 kworker/R-ata_sff
    112 FF      50   -  90 watchdogd
    115 FF      50   -  90 irq/25-AMD-Vi0-Evt
    116 FF      50   -  90 irq/26-AMD-Vi0-PPR
    117 FF      50   -  90 irq/27-AMD-Vi0-GA
    428 TS       - -20  39 kworker/R-amdgpu_dm_hpd_rx_offload_wq
    430 FF      50   -  90 card1-crtc0
    431 FF      50   -  90 card1-crtc1
    432 FF      50   -  90 card1-crtc2
    433 FF      50   -  90 card1-crtc3
    461 TS       -   0  19 nvidia-modeset/deferred_close_kthread_q
    462 FF      50   -  90 irq/62-nvidia
    475 TS       -   0  19 UVM deferred release queue
    624 FF      50   -  90 irq/63-ELAN06FA:00
    770 FF       1   -  41 psimon
    842 FF       1   -  41 psimon
   1255 FF      50   -  90 irq/96-rtw89_pci
   1513 RR      99   - 139 rtkit-daemon
   1589 FF       1   -  41 psimon
   3098 RR       1   -  41 kwin_wayland
   3098 RR       1   -  41 eDP-1
   3098 RR       1   -  41 libinput-connec
   3114 RR      20   -  60 data-loop.0
   3115 RR      20   -  60 data-loop.0
   3316 RR      20   -  60 data-loop.0
   3316 RR      20   -  60 data-loop.0
   3316 TS       -   0  19 bazaarrunner
   3316 TS       -   0  19 krunner_charrun
   3327 RR      20   -  60 data-loop.0
   6596 TS       -   0  19 WRRende~ckend#1
   6596 TS       -   0  19 WRRende~kend#19
  37282 FF       1   -  41 psimon
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest
  37326 FF      80   - 120 cyclictest

sudo cyclictest --mlockall --smp --priority=80 --interval=200 --breaktrace=800
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 11.16 5.94 3.72 19/2368 37630

T: 0 (37327) P:80 I:200 C: 268947 Min:      8 Act:   13 Avg:   13 Max:     462
T: 1 (37329) P:80 I:700 C:  76837 Min:      8 Act:   15 Avg:   13 Max:      78
T: 2 (37330) P:80 I:1200 C:  44819 Min:      9 Act:   15 Avg:   14 Max:      49
T: 3 (37331) P:80 I:1700 C:  31635 Min:      8 Act:   14 Avg:   14 Max:     153
T: 4 (37332) P:80 I:2200 C:  24443 Min:      9 Act:   15 Avg:   14 Max:     106
T: 5 (37333) P:80 I:2700 C:  19915 Min:      9 Act:   14 Avg:   14 Max:     132
T: 6 (37334) P:80 I:3200 C:  16802 Min:      9 Act:   19 Avg:   14 Max:     766
T: 7 (37335) P:80 I:3700 C:  14531 Min:      9 Act:   15 Avg:   14 Max:     179
T: 8 (37336) P:80 I:4200 C:  12800 Min:      8 Act:   21 Avg:   13 Max:      37
T: 9 (37337) P:80 I:4700 C:  11437 Min:      9 Act:   19 Avg:   14 Max:     264
T:10 (37338) P:80 I:5200 C:  10337 Min:      9 Act:   17 Avg:   14 Max:      73
T:11 (37339) P:80 I:5700 C:   9430 Min:      9 Act:   18 Avg:   14 Max:      83
# Thread Ids: 37327 37329 37330 37331 37332 37333 37334 37335 37336 37337 37338 37339
# Break thread: 37332
# Break value: 2488

sudo perf sched timehist > perf_timehist.txt awk '$1 >= 9980.792239 && $1 <= 9980.797096' perf_timehist.txt > perf_extract.txt https://pastebin.com/iuB98bXg

sudo perf sched latency > perf_latency.txt https://pastebin.com/JP0PfrSU

Hmm.

Those are very high max delay numbers. Like, a hundred plus milliseconds before a process that wanted to run code could run. I'd be expecting single digits at most. You'd expect the breakups

that's not something that you can reasonably deal with by just jacking up buffer size.

That's also not something I'd expect from normal CPU load, not unless another process has elevated priority or you were running extraordinarily high numbers of threads. Yeah, could be kernel code blocking, but those are extreme numbers. Maybe if the system is severely paging, like, out of memory.

Do you mention memory usage anywhere?

goes looking through stuff

Oh. Yeah. You did and I skimmed right past it. Okay, that'd maybe do it. You're deep in swap. Like:

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

That'd definitely create at least that much delay on rotational disks. I haven't ever tried putting my system under a lot of swap load on SSDs, but I could believe it. And someone else mentioned it too, which I ignored.

You have swap triple your physical memory and you're using using all your memory and using swap equal to time-and-a-half your physical memory.

I'd normally use maybe 100% of my memory in swap and generally try to avoid hitting it. I'm not saying that you couldn't get away with that much in swap, but if you do, most of it would have to be pretty inactive stuff.

Try killing off some of the heavy memory consumers. You can run top and hit shift-M and it'll sort by memory usage, help identify the heavy users. If the problem goes away, well, that's probably it.

If you run iostat, you should see something like this:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.52    0.02    0.26    3.13    0.00   96.08

If your %iowait number is up there, your system is probably just spending all that time paging like crazy.

So, couple things you can do.

• Obviously, not running some of the heavy memory consumers would help, see what you can pare down. Uh. You can probably save a bit by using a lighter desktop environment or something, but I can already tell you that if you're using that much, most of it's gonna be whatever software you're running, not the base system.

• If that laptop can take more memory and you can stick bigger DIMMs in

and it looks, from a quick skim, like it doesn't have soldered memory

then it looks like that thing can handle up to 64GB in SODIMMs, though I would confirm that before you go buying memory.

• If you're determined to try to run your existing apps with that hardware configuration...well, it's technically possible to use compressed swap that'll reduce the amount of I/O your system is doing (though use more CPU time). Linux has zram and zswap. zswap's the easier to enable. I haven't used it myself, but looks like if you want to enable it temporarily, for the current boot, as root, do # echo 1 >/sys/module/zswap/parameters/enabled. If it becomes tolerable after that

the max delay numbers should drop down to single digits

you can make it persistent by adding zswap.enabled=1 to the kernel command line at boot (I'd have to look up how to do that in Bazzite; on Debian, it'd be setting GRUB_CMDLINE_LINUX_DEFAULT="zswap.enabled" in /etc/default/grub and then running $ sudo update-grub).

You can maybe do something exotic like using cgroups to try to force a given process (like, not your memory player or any processes involved in playing audio) from using a lot of real memory so that it is the one that takes more of the brunt of paging, but I haven't done that myself.

After digging a bit it looks like pipewire and spotify don't get realtime shedules only SCHED_OTHER and SCHED_BATCH https://bbs.archlinux.org/viewtopic.php?pid=2279287#p2279287

   4873 TS       -   0  19 WRRende~kend#18
ludrol@bazzite:/var/home/ludrol/tmp$ ps -eo pid,class,rtprio,ni,pri,comm -L | grep -i spotify
   8613 TS       -   0  19 spotify
   8613 TS       -   0  19 spotify
   8613 TS       -   0  19 spotify
   8620 TS       -   0  19 spotify
   8620 TS       -   0  19 spotify
   8620 TS       -   0  19 spotify
   8624 TS       -   0  19 spotify
   8625 TS       -   0  19 spotify
   8664 TS       -   0  19 spotify
   8664 TS       -   0  19 spotify:cs0
   8664 B        0  19   0 spotify:disk$0
   8664 TS       -   0  19 spotify:sh0
   8664 TS       -   0  19 spotify:gdrv0
   8664 TS       -   0  19 spotify:gl0
   8664 TS       -   0  19 spotify:sh1
   8664 TS       -   0  19 spotify:sh2
   8664 TS       -   0  19 spotify:sh3
   8664 TS       -   0  19 spotify:sh4
   8664 TS       -   0  19 spotify:sh5
   8664 TS       -   0  19 spotify:sh6
   8664 TS       -   0  19 spotify:sh7
   8664 TS       -   0  19 spotify:sh8
   8664 B        0  19   0 spotify:disk$1
   8664 B        0  19   0 spotify:disk$2
   8664 B        0  19   0 spotify:disk$3
   8664 B        0  19   0 spotify:disk$0
   8664 TS       -   0  19 spotify:sh0
   8665 TS       -   0  19 spotify
   8669 TS       -   0  19 spotify
   8730 TS       -   0  19 spotify
   8804 TS       -   0  19 spotify
   8860 TS       -   0  19 spotify
ludrol@bazzite:/var/home/ludrol/tmp$ ps -eo pid,class,rtprio,ni,pri,comm -L | grep -i pipe
   2080 TS       -   0  19 IpcPipeBroadcas
   2080 TS       -   0  19 IpcPipeBroadcas
   2080 TS       -   0  19 IpcPipeBroadcas
   2080 TS       -   0  19 IpcPipeBroadcas
   3090 TS       - -11  30 pipewire
   3296 TS       - -11  30 pipewire-pulse
   3822 TS       -   0  19 .NET EventPipe
   3822 TS       -   0  19 .NET DebugPipe
   8613 TS       -   0  19 pipewire-loop
  40140 TS       -   0  19 mpv/ao/pipewire

systemctl status rtkit-daemon
● rtkit-daemon.service - RealtimeKit Scheduling Policy Service
     Loaded: loaded (/usr/lib/systemd/system/rtkit-daemon.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Thu 2026-07-16 08:42:27 CEST; 3h 3min ago
 Invocation: 71422e850ec74c97b6edfa1666d3243a
   Main PID: 1599 (rtkit-daemon)
      Tasks: 3 (limit: 16290)
     Memory: 580K (peak: 3.5M, swap: 12K, swap peak: 12K)
        CPU: 92ms
     CGroup: /system.slice/rtkit-daemon.service
             └─1599 /usr/libexec/rtkit-daemon

lip 16 08:42:38 bazzite rtkit-daemon[1599]: Successfully made thread 3090 of process 3090 (/usr/bin/pipewire) owned by '1000' high priority at nice level -11.
lip 16 08:42:38 bazzite rtkit-daemon[1599]: Successfully made thread 3095 of process 3090 (/usr/bin/pipewire) owned by '1000' RT at priority 20.
lip 16 08:42:38 bazzite rtkit-daemon[1599]: Successfully made thread 3091 of process 3091 (/usr/bin/wireplumber) owned by '1000' high priority at nice level -11.
lip 16 08:42:38 bazzite rtkit-daemon[1599]: Successfully made thread 3103 of process 3091 (/usr/bin/wireplumber) owned by '1000' RT at priority 20.
lip 16 08:42:39 bazzite rtkit-daemon[1599]: Successfully made thread 3296 of process 3296 (/usr/bin/pipewire) owned by '1000' high priority at nice level -11.
lip 16 08:42:39 bazzite rtkit-daemon[1599]: Successfully made thread 3300 of process 3296 (/usr/bin/pipewire) owned by '1000' RT at priority 20.
lip 16 08:42:41 bazzite rtkit-daemon[1599]: Successfully made thread 3837 of process 3287 (/usr/bin/plasmashell) owned by '1000' RT at priority 20.
lip 16 08:42:42 bazzite rtkit-daemon[1599]: Successfully made thread 4081 of process 3287 (/usr/bin/plasmashell) owned by '1000' RT at priority 20.
lip 16 08:42:43 bazzite rtkit-daemon[1599]: Successfully made thread 4331 of process 4070 (/var/home/ludrol/.local/share/Steam/ubuntu12_32/steam) owned by '1000' high priority at nice level -10.
lip 16 08:42:44 bazzite rtkit-daemon[1599]: Successfully made thread 4332 of process 4070 (/var/home/ludrol/.local/share/Steam/ubuntu12_32/steam) owned by '1000' high priority at nice level -10.

I tried to force a clanker to help me, but it can only get me so far.

I have run sudo perf sched record -- sleep 5 with spotify and stress-ng and without easy effects but it didn't really tell about what was blocking the thread, or what could be the problem.

 -------------------------------------------------------------------------------------------------------------------------------------------
  Task                  |   Runtime ms  |  Count   | Avg delay ms    | Max delay ms    | Max delay start           | Max delay end          |
 -------------------------------------------------------------------------------------------------------------------------------------------
  TaskCon~ller #4:(2)   |      0.083 ms |        3 | avg:   8.605 ms | max:  22.177 ms | max start:  2225.534477 s | max end:  2225.556654 s
  dex-thread-pool:(3)   |      6.973 ms |        7 | avg:   8.459 ms | max:  22.054 ms | max start:  2227.176387 s | max end:  2227.198441 s
  spotify:(5)           |    390.149 ms |      855 | avg:   8.354 ms | max: 198.827 ms | max start:  2227.285930 s | max end:  2227.484757 s
  WRScene~derLP#1:5028  |      2.360 ms |      194 | avg:   7.097 ms | max:  76.383 ms | max start:  2226.890377 s | max end:  2226.966759 s
  ThreadPoolServi:8864  |      0.101 ms |        3 | avg:   6.935 ms | max:  20.742 ms | max start:  2226.356434 s | max end:  2226.377175 s
  Media:8854            |     53.526 ms |      394 | avg:   6.881 ms | max: 107.856 ms | max start:  2226.212405 s | max end:  2226.320261 s
  VizCompositorTh:8780  |     77.461 ms |      562 | avg:   6.859 ms | max:  83.443 ms | max start:  2227.253999 s | max end:  2227.337441 s
  Core Thread:8688      |      7.656 ms |      105 | avg:   6.800 ms | max:  77.954 ms | max start:  2229.299488 s | max end:  2229.377442 s
  Connect Discove:8725  |      0.286 ms |        8 | avg:   6.768 ms | max:  16.469 ms | max start:  2227.202786 s | max end:  2227.219255 s
  Network Thread:8708   |      6.427 ms |       76 | avg:   6.677 ms | max:  40.636 ms | max start:  2229.901403 s | max end:  2229.942039 s
  WRScene~ilder#1:5027  |      3.435 ms |      211 | avg:   6.582 ms | max:  79.265 ms | max start:  2226.887473 s | max end:  2226.966738 s
  File Streamer I:8711  |      9.539 ms |      100 | avg:   5.854 ms | max:  44.024 ms | max start:  2227.061508 s | max end:  2227.105532 s
  ThreadPoolForeg:(6)   |      5.587 ms |       59 | avg:   5.745 ms | max:  32.582 ms | max start:  2225.737484 s | max end:  2225.770066 s
  KIO::WorkerThre:(2)   |      1.832 ms |       22 | avg:   5.452 ms | max:  20.065 ms | max start:  2229.568516 s | max end:  2229.588581 s
  Desktop EventSe:8689  |      0.595 ms |        1 | avg:   5.057 ms | max:   5.057 ms | max start:  2225.703380 s | max end:  2225.708437 s
  spotify:cs0:8750      |     15.509 ms |      245 | avg:   5.056 ms | max:  51.215 ms | max start:  2227.051346 s | max end:  2227.102561 s
  VideoFrameCompo:8855  |     29.563 ms |      337 | avg:   4.979 ms | max:  47.150 ms | max start:  2227.483466 s | max end:  2227.530616 s
  WRRende~ckend#1:5029  |     18.610 ms |      336 | avg:   4.894 ms | max:  69.204 ms | max start:  2227.019314 s | max end:  2227.088517 s
  Chrome_IOThread:(2)   |      9.801 ms |      132 | avg:   4.686 ms | max:  35.030 ms | max start:  2229.786608 s | max end:  2229.821638 s
  glean.dispatche:4896  |      7.905 ms |      379 | avg:   4.599 ms | max:  71.021 ms | max start:  2226.969815 s | max end:  2227.040835 s
  WebExtensions:5078    |     83.091 ms |      254 | avg:   3.902 ms | max:  43.411 ms | max start:  2227.657268 s | max end:  2227.700679 s
  Chrome_ChildIOT:(5)   |     38.349 ms |      940 | avg:   3.864 ms | max:  57.356 ms | max start:  2225.249786 s | max end:  2225.307142 s
  ThreadPoolSingl:(2)   |     37.049 ms |      570 | avg:   3.811 ms | max:  58.063 ms | max start:  2227.475541 s | max end:  2227.533604 s
  TaskCon~ller #1:(2)   |      5.080 ms |       83 | avg:   3.688 ms | max:  34.766 ms | max start:  2227.041677 s | max end:  2227.076443 s
  TaskCon~ller #0:(4)   |     17.486 ms |      162 | avg:   3.036 ms | max:  39.163 ms | max start:  2227.452333 s | max end:  2227.491496 s
  Audio Driver Th:8718  |     15.663 ms |      513 | avg:   2.887 ms | max:  48.186 ms | max start:  2227.368253 s | max end:  2227.416439 s
  firefox:cs0:4943      |      4.029 ms |       56 | avg:   2.884 ms | max:   9.819 ms | max start:  2228.624509 s | max end:  2228.634328 s
  Renderer:4966         |     16.666 ms |      133 | avg:   2.751 ms | max:  36.844 ms | max start:  2227.794477 s | max end:  2227.831321 s
  bazaar:8465           |      0.190 ms |        3 | avg:   2.720 ms | max:   8.111 ms | max start:  2227.223328 s | max end:  2227.231439 s
  IPC I/O Parent:4898   |      5.250 ms |      206 | avg:   2.573 ms | max:  22.691 ms | max start:  2227.468762 s | max end:  2227.491453 s
  Media Mixer Ren:8882  |     39.110 ms |      478 | avg:   2.484 ms | max:  39.760 ms | max start:  2229.637725 s | max end:  2229.677485 s
  mpris-proxy:2576      |      0.648 ms |        5 | avg:   2.477 ms | max:   5.067 ms | max start:  2226.065870 s | max end:  2226.070938 s
  JS Watchdog:(5)       |      0.480 ms |       21 | avg:   2.434 ms | max:  23.796 ms | max start:  2226.863646 s | max end:  2226.887442 s
  SteamUIWatchdog:4443  |      0.025 ms |        1 | avg:   2.391 ms | max:   2.391 ms | max start:  2229.533194 s | max end:  2229.535585 s
  DOM Worker:15552      |      4.313 ms |       28 | avg:   2.111 ms | max:   8.721 ms | max start:  2225.547973 s | max end:  2225.556694 s
  Compositor:(2)        |    125.776 ms |     2106 | avg:   2.076 ms | max: 119.343 ms | max start:  2229.776914 s | max end:  2229.896257 s
  Timer:(10)            |      8.823 ms |      416 | avg:   2.054 ms | max:  42.432 ms | max start:  2226.970019 s | max end:  2227.012451 s
  dolphin:9296          |     31.250 ms |      117 | avg:   1.963 ms | max:  21.491 ms | max start:  2228.605754 s | max end:  2228.627245 s
  TaskCon~ller #3:(2)   |      1.196 ms |       35 | avg:   1.848 ms | max:  22.169 ms | max start:  2225.534467 s | max end:  2225.556635 s
  TaskCon~ller #2:(2)   |      3.287 ms |       50 | avg:   1.644 ms | max:  22.594 ms | max start:  2225.534012 s | max end:  2225.556605 s
  pipewire-loop:8884    |     20.933 ms |      511 | avg:   1.583 ms | max:  42.681 ms | max start:  2227.302468 s | max end:  2227.345149 s

[…]

  pipewire-pulse:3296   |     19.050 ms |      727 | avg:   0.123 ms | max:   0.994 ms | max start:  2229.906447 s | max end:  2229.907441 s

https://pastebin.com/nZnGf2fP

clanker has seen cyclictest and sudo trace-cmd record -e sched -e irq -e timer -e workqueue -e power -e signal so I tried running that

sudo cyclictest --mlockall --smp --priority=80 --interval=200 --breaktrace=1000
# /dev/cpu_dma_latency set to 0us
policy: fifo: loadavg: 8.00 2.89 2.49 24/1847 16763          

T: 0 (16700) P:80 I:200 C: 144467 Min:      6 Act:   13 Avg:   11 Max:     376
T: 1 (16701) P:80 I:700 C:  41270 Min:      7 Act:   15 Avg:   11 Max:      98
T: 2 (16702) P:80 I:1200 C:  24071 Min:      7 Act:   12 Avg:   12 Max:     130
T: 3 (16703) P:80 I:1700 C:  16989 Min:      8 Act:   15 Avg:   12 Max:     107
T: 4 (16704) P:80 I:2200 C:  13126 Min:      7 Act:   19 Avg:   12 Max:     104
T: 5 (16705) P:80 I:2700 C:  10694 Min:      8 Act:   20 Avg:   12 Max:      58
T: 6 (16706) P:80 I:3200 C:   9022 Min:      8 Act:   16 Avg:   13 Max:      56
T: 7 (16707) P:80 I:3700 C:   7802 Min:      8 Act:   12 Avg:   13 Max:     101
T: 8 (16708) P:80 I:4200 C:   6872 Min:      8 Act:   10 Avg:   12 Max:      27
T: 9 (16709) P:80 I:4700 C:   6140 Min:      9 Act:   12 Avg:   13 Max:      47
T:10 (16710) P:80 I:5200 C:   5549 Min:      9 Act:   15 Avg:   13 Max:      83
T:11 (16711) P:80 I:5700 C:   5061 Min:      9 Act:   14 Avg:   14 Max:      31
# Thread Ids: 16700 16701 16702 16703 16704 16705 16706 16707 16708 16709 16710 16711
# Break thread: 16705
# Break value: 3337

I have extracted the scheduler events between ~8ms delay of 16705 thread, but I don't know how to tackle it.

https://pastebin.com/D4bbzqT7

Thanks. Looks like I am one of lucky 10000 to learn about real time schedulers.