It does not, it serves no purpose for only listening to music.

Producing, broadcasting, or any sort of scenario that require reliable low latency can benefit from a real time kernel, but not merely listening to music.

It’s very helpful for performing music

I sometimes play live (I don’t enjoy it) using Spectrasonic’s Keyscape, which loads many dozens of gigabytes into RAM. If I have one more “mystery” buffering issue I’m going to tear my hair out

This is on an ultra locked down, high spec dedicated PC

I would be absolutely enthralled if my software/hardware had a consistent schedule like that prioritised by an actual RTOS

It’s why almost all actual musicians use industry standards like Nord for keyboards. While my Keyscape VST sounds much better, I can’t reliably use it in live contexts because the Windows/Mac stacks are just too precarious

I don’t need it to crush numbers, just have the gap between best case and worst case scenario for computation to be effectively zero

Live performance craves near-deterministically performing instruments and tooling

RTOS does not improve playback of music but is crucial if you e.g. want to produce music. Imagine a situation where you connect some MIDI keyboard and play some music - you want OS to produce the sound "real time" instead of "scheduling it".

No purpose here, it's classic "audiophile". From https://mpd.readthedocs.io/en/stable/user.html#real-time-sch...

"Note There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load."

If your audiophile playback machine is under "heavy load" then you are definitely suffering a bad case of priority inversion.

RTOS means that if you are listening to music and doing something else the music plays without issues (clicks). Take a modern 16 core computer and load it up such that the load average is over 200 and your sound playing will have issues. Of course realistically nobody loads their computer down that much, but if you manage to anyway like that you will have issues with sound. Because you won't though RTOS won't matter for playback. Still if you try you can cause issues without a RTOS - I leave this as an exercise to the reader.

As other have said RTOS is critical for live sound because there they have to make compromises that mean much less load is needed to cause issues. If you configure your sound playback with the same compromises you will see issues on playback - but for just playing music on a regular computer those compromises are a don't do that situation.

Theoretically, an RTOS improves the quality by ensuring that the audio subsystem is fed cpu time and data with enough granularity that there is no interruption or delay on the sound stream (no "buffer underruns") and there are no glitches on the output.

In practice this should not be an issue if you are just playing music (at worst, add some more buffering) but it can be if the music must be synchronized with something else and you need low latency AND the system is busy doing also something else.

I found Linux in particular to be surprisingly bad at this when mass storage is involved (copy files on a spinning disk, somehow playback of audio from an SSD is affected... why?), although low-latency versions of the kernel help in that regard.