RegularJogger This kind of troubleshooting requires ruling out things and checklists. We just ruled out one thing. Your contribution didn't go to waste and is appreciated. Making sure it's not cpu scaling/throttling will certainly help everyone with "modern" power management on their machine. Your advice wasn't outdated. It's more relevant today more than ever. Cheers!

In the meantime let's see if next Solus update changes anything. There was something concerning linux-audio, didn't inspect them too much, let's see where it goes.

5 days later

Problem not solved, bad cracking in sound remains.
What would be next thing to check?

I find this strange:
I launch QjackCtl, then I launch Guitarix. I strum guitar strings. Sound is crackling. I stop and quit QjackCtl. Guitarix remains running. Crackling sound stil comes through Guitarix, even if I just stopped and quit QjackCtl. I can't see anything jack related process from System Monitor while Guitarix is still showing appropriate jack ports ticked. Isn't something wrong with that? I would expect to see some jack process in System Monitor. Really confusing!

Do you have realtime checked in qjackctl settings?
You don't see jackd because pipewire is the sound server.

    plutuplutu Yes, there's realtime tick box which is ticked in QjackCtl. Also QjackCtl's "display" indicates Active "RT" (flashing) and about 87% - 2000% DSP load.

    plutuplutu You don't see jackd because pipewire is the sound server

    Ok, I thought pipewire should become jack's client.

    I managed to install this analysis software: https://codeberg.org/rtcqs/rtcqs
    It gives me this error: Could not find kernel configuration.

    What would that mean then? Their Wiki is empty. Anyone familiar with this tool?

    plutuplutu Great find, thank you!
    No I haven't tried that but I will try that next.
    One thing I never remember: There are two tick box options in QjackCtl. 1. Enable D-Bus interface 2. Enable JACK D-Bus interface. Which one or both enabled? I'd guess nr.2 enabled in this case, and nr.1 is for QjackCtl itself (something like that?) and for other(?) reasons than starting jack server. Please correct me if I'm wrong.

    Axios Thanks for suggestion. Unfortunately those instructions are outdated. They don't work anymore because of Pipewire. For example setting buffer size via QjackCtl is impossible. There's some info regarding D-Bus though, that could be relevant also with pipewire (like suggested in @plutuplutu 's link), I guess. I don't know!

    6 days later

    For anyone who may be interested in low-latency audio issues with Solus & pipewire, here's sequel to previous.

    Things that I've tweaked since last post:

    • Set kernel parameters preempt=full threadirqs mitigations=off

    I've added the parameters following these *instructions:
    https://help.getsol.us/docs/user/quick-start/boot-management

    *I happened to notice (!), that this procedure is little different in Solus, compared to usual GRUB modification instructions, which one can find for example at debian/ubuntu forums.

    Sources of advice (for me to try these things):

    https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#kernel
    https://wiki.linuxaudio.org/wiki/system_configuration#:~:text=Using%20the%20threadirqs%20kernel%20option
    https://wiki.linuxaudio.org/wiki/system_configuration#:~:text=Disabling%20Spectre%20and%20Meltdown%20mitigations

    Results: There was notable improvements, but still not enough. For example, I don't notice broken sound anymore while watching/listening online content. With guitarix, I can now lower the latency to 256 and sound is borderlining broken/solid. Previously at 256 it was garbled mess.
    Aim here would be under or no more than 10 ms round trip latency with pristine sound quality.
    So, "Close, but no cigar". There must be some fundamental things still wrong with pipewire and I guess that makes waiting for updates like waiting for Christmas.

    Have you tried setting @audio - rtprio to 99, instead of 95 like there, in /etc/security/limits.conf? I don't even have memlock unlimited there and I never saw any Xruns. It sickens me a little to see your problem is still not solved, to the point I might install Guitarix to see how it behaves here.

      plutuplutu It would be very interesting to hear how guitarix works for you. If/when you got the time, go ahead, check it out. If not, no worries.
      I haven't seen that "@audio - rtprio to 99" done before, nor have I tried that. Could you explain the logic behind that one, for me, please. Because if it's simlpy more=more, then I'm doubting it's effectiveness. Sorry for questioning this, it's just that I'd like to understand all the reasoning behind what I'm tweaking, as much as I can.
      From what I understand, the hierarchy of those priority- numbers are more important than the actual numbers, which leads me to realise, that I really don't know what proper hierarchy would be in low-latency-audio setup. Example: jack=some-high-number. pipewire=some-high-number, BUT, equal, lower or higher than jack? The link from your earlier post (Wim Taymans, Fedora forum) suggests that equal. But then, wouldn't that lead to Race Conditions. I don't know, I'm just nerd-bug bitten guitar player.
      All that said, sure, I try 99 at some point. Thanks for supportive attitude!

        Guitarix tested. Lowest latency without (too much) Xruns: 128 samples@48kHz. I remember working with 3 buffers of 64 samples (192 samples) in jack with the same hardware (lenovo laptop/cheap behringer usb soundcard).

        qk4-li3 Could you explain the logic behind that one

        My wild guess is that the higher it is, the more realtime priority the audio apps gets. I wouldn't try 100, though.

        Additional things to try: "non standard period size values of 48 96 144 192 240 288 336 384 432 480 528".
        Source: https://linuxmusicians.com/viewtopic.php?t=26271

        Useful commands to do so:

        • pw-metadata -n settings display pipewire settings
        • pw-metadata -n settings 0 clock.force-quantum <buffer-size> temporarily forces buffer size
        • pw-metadata -n settings 0 clock.force-quantum 0 back to default buffer size

        Source: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#runtime-settings

          5 days later

          plutuplutu Congratulations, you lucky one! I guess you got your stars aligned, or moon was in the right position etc. Nice to know. Nice to know your hardware specs too. I've got Focusrite box (clarett+4pre) and quite old DIY Desktop, Asus mobo (P5B-E), Intel cpu Q6600 @2.4Ghz.
          There's quite a rabbit hole there through those links, but here's what I got now:
          Choosing non-standard period size values seems to have some effect. Some values seem to work better than others. Playing guitar through guitarix, at best, the sound is intact, with no notable or disturbing latency (which is nice), but only for a few *strums, until sound is intermittent. *(I'd say during 1 to 5 seconds there's breakage in sound).
          Next, I think I'll investigate is there any existing firmware updates to my focusrite box.
          Thanks for support and ideas!