5 ms·

Wait, so should casual desktop Linux users try this out too? I assumed there must be some trade-off to using RT?

femto 2y ago
It's every so slightly slower, but the difference is negligible and won't be noticed on a desktop machine. These days, I just run the (Debian) real-time kernel as a matter of course on my everyday machine. I haven't objectively tested it, but my feeling is that it actually makes for a nicer user experience. Sometimes Gnome can briefly freeze or feel sluggish (presumably the CPU is off doing something) and I feel that the RT kernel does away with this. It could be a placebo effect though.
- ChocolateGod 2y ago
  > It's every so slightly slower in what way? I'd say responsiveness is more important to the desktop than raw performance and from my experience with nearly 2 decades of using Linux desktops, responsiveness has never been great. If I'm switching between windows whilst encoding a video in the background, the window manager should have instant priority even if it means starving the background task of some CPU time. on GNOME this is quite bad, run a very heavy task (e.g. AI) in the background and the desktop will start to suffer.
- irundebian 2y ago
  I doubt that RT makes a nicer user experience on desktops. You are probably better of switching to another desktop-oriented scheduler.
cwillu 2y ago
Not really any harm in trying, but definitely note that the trail marked “trying scheduler changes to see if it improves desktop performance” is strewn with skeletons, the ghosts thereof haunt audio forums sayings things like “[ghostly] oooooohhhh, the sound is so much clearer now that I put vibration dampeners under my usb audio interface”. The reason I wrote my original comment is precisely because “audio xruns at a higher latency with lower system load” is a very concrete measure of improvement that I can't fool myself about, including effects like “the system runs better when freshly booted for a while” that otherwise bias the judgements of the uninitiated towards “…and therefore the new kernel improved things!” There isn't much on a desktop that is sensitive to latency spikes on the order of a couple ms, which a stock kernel should already be able to maintain.
- snvzz 2y ago
  It can literally sound better (objectively). Suppose your audio server attempts fancy resampling, but falls back to a crude approximation after the first xrun.
  - cwillu 2y ago
    Theoretically possible, but show me a sound server that automatically drops resampling quality instead of just increasing the buffer size.
    - snvzz 2y ago
      That's a different knob that can be used; Increasing buffer size simply is a different compromise to achieve the result of meeting audio deadlines. Quality vs latency, pick one. Or just use PREEMPT_RT to tighten the timings for the critical audio worker getting the cpu ;)
      - cwillu 2y ago
        JERRY: We didn't bet on if you wanted to. We bet on if it would be done. KRAMER: And it could be done. JERRY: Well, of course it could be done! Anything could be done! But it only is done if it's done. Show me the levels! The bet is the levels. Again, the point isn't that there is a possible tradeoff to be made, nor that the configuration option isn't available, nor even that some people tweak that setting for this very reason. It was stated that better RT performance will automatically improve audio quality because the audio system may automatically switch resampling methods on xrun, and that is specifically what I'm doubting. The bet isn't that it could be done. Anything could be done! Show me that it is being done!
        snvzz 2y ago
        A true audiophile can tell. Nevermind switching approaches to interpolation; The microjitter is blatant, and the plankton is lost.
bityard 2y ago
The trade off is reduced throughput. How much depends a lot on the system and workload.

It's every so slightly slower, but the difference is negligible and won't be noticed on a desktop machine. These days, I just run the (Debian) real-time kernel as a matter of course on my everyday machine. I haven't objectively tested it, but my feeling is that it actually makes for a nicer user experience. Sometimes Gnome can briefly freeze or feel sluggish (presumably the CPU is off doing something) and I feel that the RT kernel does away with this. It could be a placebo effect though.

ChocolateGod 2y ago
> It's every so slightly slower in what way? I'd say responsiveness is more important to the desktop than raw performance and from my experience with nearly 2 decades of using Linux desktops, responsiveness has never been great. If I'm switching between windows whilst encoding a video in the background, the window manager should have instant priority even if it means starving the background task of some CPU time. on GNOME this is quite bad, run a very heavy task (e.g. AI) in the background and the desktop will start to suffer.
irundebian 2y ago
I doubt that RT makes a nicer user experience on desktops. You are probably better of switching to another desktop-oriented scheduler.

cwillu 2y ago

Not really any harm in trying, but definitely note that the trail marked “trying scheduler changes to see if it improves desktop performance” is strewn with skeletons, the ghosts thereof haunt audio forums sayings things like “[ghostly] oooooohhhh, the sound is so much clearer now that I put vibration dampeners under my usb audio interface”. The reason I wrote my original comment is precisely because “audio xruns at a higher latency with lower system load” is a very concrete measure of improvement that I can't fool myself about, including effects like “the system runs better when freshly booted for a while” that otherwise bias the judgements of the uninitiated towards “…and therefore the new kernel improved things!” There isn't much on a desktop that is sensitive to latency spikes on the order of a couple ms, which a stock kernel should already be able to maintain.

snvzz 2y ago
It can literally sound better (objectively). Suppose your audio server attempts fancy resampling, but falls back to a crude approximation after the first xrun.
- cwillu 2y ago
  Theoretically possible, but show me a sound server that automatically drops resampling quality instead of just increasing the buffer size.
  - snvzz 2y ago
    That's a different knob that can be used; Increasing buffer size simply is a different compromise to achieve the result of meeting audio deadlines. Quality vs latency, pick one. Or just use PREEMPT_RT to tighten the timings for the critical audio worker getting the cpu ;)
    - cwillu 2y ago
      JERRY: We didn't bet on if you wanted to. We bet on if it would be done. KRAMER: And it could be done. JERRY: Well, of course it could be done! Anything could be done! But it only is done if it's done. Show me the levels! The bet is the levels. Again, the point isn't that there is a possible tradeoff to be made, nor that the configuration option isn't available, nor even that some people tweak that setting for this very reason. It was stated that better RT performance will automatically improve audio quality because the audio system may automatically switch resampling methods on xrun, and that is specifically what I'm doubting. The bet isn't that it could be done. Anything could be done! Show me that it is being done!
      - snvzz 2y ago
        A true audiophile can tell. Nevermind switching approaches to interpolation; The microjitter is blatant, and the plankton is lost.

bityard 2y ago

The trade off is reduced throughput. How much depends a lot on the system and workload.