Real-Time "PREEMPT_RT" Support Merged For Linux 6.12

[Zastrix]

You won't get more FPS. Nor magically make the frame rate more consistent.

At the moment with the normal kernel, enabling preempt=full will actually increase your FPS and make your FPS more stable in games and while I'm recording audio I get way less stutters what trying to user lower buffer sizes. I'll have to try out on 6.12-rc1 and see how it'll work though. Definitely some form of preempt will help if you're running the basic kernel arguments.

[wertigon]

At the moment with the normal kernel, enabling preempt=full will actually increase your FPS and make your FPS more stable in games and while I'm recording audio I get way less stutters what trying to user lower buffer sizes. I'll have to try out on 6.12-rc1 and see how it'll work though. Definitely some form of preempt will help if you're running the basic kernel arguments.

preempt=full is not preempt_rt.

preempt=full is low latency preemption. RT is one preemption level above that.

[F.Ultra]

Buffers dont help if your timestamps are not accurate.

The fundamental point of the real time stuff is making sure timing is precise. That has benefits for developing anything that requires precise timing; all audio/visual stuff, motion sensing for things like VR controllers.

While that mostly evolved in situations where it was 100% essential - when imprecise timing could have fatal consequences, as a toolkit it has a lot of benefits for all sorts of development which over time is going to push linux even further ahead of legacy operating systems.

you don't need any timestamps when sampling audio or performing playback since the data rate is constant.

[wertigon]

you don't need any timestamps when sampling audio or performing playback since the data rate is constant.

I wish people would actually read what I wrote sometimes :P

1. Digital Audio Workstation (DAW) providing a much less jagged input and output mixing experience. This is currently mostly handled by software filters, but now you can guarantee samplings every nth millisecond.

For playback RT is not required, I was specifically talking about the creative side of music. The one that mixes music in realtime with human timings.

[F.Ultra]

I wish people would actually read what I wrote sometimes :P

That was a reply to a different person and a different claim though.

[mSparks]

you don't need any timestamps when sampling audio or performing playback since the data rate is constant.

the data rate is only constant if your kernel is running in real time - thats the point of a real time kernel.

If its not a real time kernel then every sample will have time error introduced by things like cache misses or interrupts.
Now, that wont matter for audio (matters a lot for motion sensing) if your processor is running at Ghz, because a few tens of nanoseconds error here and there wont make much of a difference.
matters a lot on smaller embedded devices running at Mhz, because a sample being played 20ms to late or to early or missing entirely will very much ruin the audio quality even for the most tone deaf of listeners.

[F.Ultra]

the data rate is only constant if your kernel is running in real time - thats the point of a real time kernel.

If its not a real time kernel then every sample will have time error introduced by things like cache misses or interrupts.
Now, that wont matter for audio (matters a lot for motion sensing) if your processor is running at Ghz, because a few tens of nanoseconds error here and there wont make much of a difference.
matters a lot on smaller embedded devices running at Mhz, because a sample being played 20ms to late or to early or missing entirely will very much ruin the audio quality even for the most tone deaf of listeners.

your context was that buffers where used, if you are sampling at say 24bit 96khz with buffers then you know exactly what the timestamps are since the hardware sampler will produce buffered data at exact intervals and with a constant rate. Every 3 bytes moves the time 10.417µs (if we assume single channel). Cache misses and/or interrupts will not make any change here since this is all done inside the audio capture hardware.

If you for some strange reason want to perform audio sampling in software on the cpu then use isolcpu and taskset the threads of your daw on the isolated cores. This will give you far less latency and jitter than using PREEMPT_RT.

[mSparks]

your context was that buffers where used, if you are sampling at say 24bit 96khz with buffers then you know exactly what the timestamps are since the hardware sampler will produce buffered data at exact intervals and with a constant rate. Every 3 bytes moves the time 10.417µs (if we assume single channel). Cache misses and/or interrupts will not make any change here since this is all done inside the audio capture hardware.

on the cpu then use isolcpu and taskset the threads of your daw on the isolated cores. This will give you far less latency and jitter than using PREEMPT_RT.

And all that breaks as soon as you try and put that "precise 96khz sampling" into any kind of dsp that is not running on a realtime kernel.

That is exactly why you have chips like the AC97 handling all audio - because the non RT compute is not capable.

The point of an RT kernel is it gives those same capabilities to the rest of the CPU - nothing to do with "buffers".

If you for some strange reason want to perform audio sampling in software.

Audio Synthesis is not strange, certainly far, far less rare than recording direct to raw and playing it directly back with no compression or software defined audio filters.

[F.Ultra]

And all that breaks as soon as you try and put that "precise 96khz sampling" into any kind of dsp that is not running on a realtime kernel.

That is exactly why you have chips like the AC97 handling all audio - because the non RT compute is not capable.

The point of an RT kernel is it gives those same capabilities to the rest of the CPU - nothing to do with "buffers".

If that breaks then a RT kernel cannot help you either, isolcpu and taskset gives you way more RT than the rt patches can ever achieve.

[mSparks]

If that breaks then a RT kernel cannot help you either, isolcpu and taskset gives you way more RT than the rt patches can ever achieve.

the rt kernel gives you precise time guarantees, thats what it does.

no RT, no "precise 96kHz data flow", because the timing is non deterministic. RT = deterministic timing = accurate handling of time sensitive samples.

You should look into what the RT stuff is doing and how it works, it sounds like you dont actually know what it means.

This seems like a good summary

https://www.youtube.com/watch?v=7hwoJanE5-U