5 ms·

Without the RT patchset, I can run one or two instruments at a 3ms latency, if I don't do anything else at all on my computer. With it, I routinely have 6 inst

by cwillu 2y ago

Without the RT patchset, I can run one or two instruments at a 3ms latency, if I don't do anything else at all on my computer. With it, I routinely have 6 instruments at 1ms, while having dozens of chrome windows open and playing 3d shooters without issue. It's shocking how much difference it makes over the regular (non-rt) low latency scheduler.

freedomben 2y ago
6 instruments at 1ms, that's great! Are these MIDI instruments or audio in? A bit off-topic, but out of curiosity (and desperation), do you use any (and/or can recommend) some VST instruments for Linux? Do you experience any downsides running the RT scheduler?
- cwillu 2y ago
  Nothing specific to the RT scheduler that I've noticed; there is a constant overhead from the audio stuff, but that's because of the workload (enabled by RT), not because of the RT itself. My usual setup has 2 PianoTeq (physically modelled piano/electric piano/clavinet) instances, 3 SurgeXT instances (standard synthesizer), a setBfree (Tonewheel/hammond simulator) instance, and a handful of sequencers and similar for drums, as well as a bunch of routing and compressors and such.
  - darkwater 2y ago
    Out of curiosity, what music do you compose? How would you judge the Linux experience doing so, outside the RT topic? Do you have any published music you will to share? Thanks!
p1necone 2y ago
Is there a noticeable difference in performance in the less latency sensitive stuff? (e.g. lower fps in the games)
- deleted 2y ago
  [deleted]
- nine_k 2y ago
  I would not expect lower FPS, because the amount of available CPU does not materially change. I would expect higher latency, because RT threads would more often scheduled ahead of other threads.
- cwillu 2y ago
  GPU-bound stuff is largely unaffected; CPU-bound definitely takes a hit (although there's no noticeable additional latency on non-RT tasks), but that's kinda to be expected.
nixosbestos 2y ago
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.

by cwillu 2y ago

freedomben 2y ago

6 instruments at 1ms, that's great! Are these MIDI instruments or audio in? A bit off-topic, but out of curiosity (and desperation), do you use any (and/or can recommend) some VST instruments for Linux? Do you experience any downsides running the RT scheduler?

cwillu 2y ago
Nothing specific to the RT scheduler that I've noticed; there is a constant overhead from the audio stuff, but that's because of the workload (enabled by RT), not because of the RT itself. My usual setup has 2 PianoTeq (physically modelled piano/electric piano/clavinet) instances, 3 SurgeXT instances (standard synthesizer), a setBfree (Tonewheel/hammond simulator) instance, and a handful of sequencers and similar for drums, as well as a bunch of routing and compressors and such.
- darkwater 2y ago
  Out of curiosity, what music do you compose? How would you judge the Linux experience doing so, outside the RT topic? Do you have any published music you will to share? Thanks!

p1necone 2y ago

Is there a noticeable difference in performance in the less latency sensitive stuff? (e.g. lower fps in the games)

deleted 2y ago
[deleted]
nine_k 2y ago
I would not expect lower FPS, because the amount of available CPU does not materially change. I would expect higher latency, because RT threads would more often scheduled ahead of other threads.
cwillu 2y ago
GPU-bound stuff is largely unaffected; CPU-bound definitely takes a hit (although there's no noticeable additional latency on non-RT tasks), but that's kinda to be expected.

nixosbestos 2y ago

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.