KLV-SpectrwmCE-sr4 with a Void Linux Kernel 6.11.11_1

[rockedge]

KLV-SpectrwmCE-sr4 is an updated version of KLV-SpectrwmCE-v3 which is a KLV-Spectr fine tuned and polished by @Sofiya with a Void Linux kernel 6.11.11_1.

KLV-SpectrwmCE-sr4 uses the Spectrwm tiling window manager for a desktop enviroment. It is equipped with pipewire audio and has wayland components

This system is fully compatible with upstream official Void Linux repos and utilizes the XBPS pacjkage manager. OctoXBPS is included for a GUI approach to using xbps.

Also the huge full real time kernels will work with this version as can most other modular huge kernels and can be swapped in easily if the Void Linux kernel is not preferred.

This distro has all of the power of KLV-Spectr-sr3 and KLV-Spectr-RT but with the Spectrwm desktop even further designed and fine tuned by @Sofiya , who is a true master of Distro creation, design and beauty. Her work speaks for itself.

Download location -> https://mega.nz/folder/flZT3axZ#DDnKrpy0pdhqhrB3EflVRg

[geo_c]

KLV-SpectrwmCE-sr4 is an updated version of KLV-SpectrwmCE-v3 which is a KLV-Spectr fine tuned and polished by @Sofiya with a Void Linux kernel 6.11.11_1.

KLV-SpectrwmCE-sr4 uses the Spectrwm tiling window manager for a desktop enviroment. It is equipped with pipewire audio and has wayland components

This system is fully compatible with upstream official Void Linux repos and utilizes the XBPS pacjkage manager. OctoXBPS is included for a GUI approach to using xbps.

Also the huge full real time kernels will work with this version as can most other modular huge kernels and can be swapped in easily if the Void Linux kernel is not preferred.

This distro has all of the power of KLV-Spectr-sr3 and KLV-Spectr-RT but with the Spectrwm desktop even further designed and fine tuned by @Sofiya , who is a true master of Distro creation, design and beauty. Her work speaks for itself.

Download location -> https://mega.nz/folder/flZT3axZ#DDnKrpy0pdhqhrB3EflVRg

This is great. I will work with the 6.11.11_1 kernel, because I have to be very careful about doing certain audio operations using the real time kernel you put together some time ago. For instance I have to scale the max frequency back whether using power saver governor or not when using the export audio routine in Ardour 8. If I don't scale back the max processor speed on my Dell Optiplexes, I get processor number 5 running full out 100% and reaching the fail safe core temp. It hasn't yet caused the bios to shut down, but it's concerning. It's a similar scenario if I use mksquashfs. In that operation all processors run max until the file is squashed.

I'm attributing that to the real time scheduling, but maybe it's not. When I get around to testing this iso I'll try and get a feel for the difference between the kernels.

This gives me a good reason to reload and rebuild Spectr again.

[Clarity]

Hello @geo_c
I am NOT a musician, although in my college years I managed a band. Further, I have NOT done anything in over 30 years in using some of the boards connected to personal systems of the past.

Since this OOTB kernel is general purposed, and many of today's CPUs, in user hands, are very fast by comparisons of when real-time was initially popular, I am curious to see what you find in how the app behaves when running it on this newer pipewire based system.

Guessing that it will not stack-up, locked, embracing a single CPU and audio ability/quality wont suffer.

Looking forward

[geo_c]

Hello @geo_c
I am NOT a musician, although in my college years I managed a band. Further, I have NOT done anything in over 30 years in using some of the boards connected to personal systems of the past.

Since this OOTB kernel is general purposed, and many of today's CPUs, in user hands, are very fast by comparisons of when real-time was initially popular, I am curious to see what you find in how the app behaves when running it on this newer pipewire based system.

Guessing that it will not stack-up, locked, embracing a single CPU and audio ability/quality wont suffer.

Looking forward

I've been running three KL pipewire distros for some time now using all the jack apps. Ardour is both pipewire-jack or pipewire-alsa capable. I tend to run it under pipewire-jack. The three KLs are KLV-spectr, KLV-airedale, and KLV-KDE-Plasma, and Plasma may not be using @rockedge's 6.1.38 RT kernel. I'll have to check whether I swapped that one out. Also I haven't really used KDE-Plasma for any extended work for two main reasons.

First, a significant number of lv2,/vst plugins by nature tend to be quirky, buggy, and outright crash at times, causing Ardour to bomb out. I attribute that to their heavy/complex graphic load. They tend crash when manipulating the settings graphically while the tracks are running. So adding the wayland Plasma interface into the mix doesn't seem to make that interaction any more stable.

Second, as an audio project grows, every bit of processing power begins to matter. I'm regularly using 16GB of ram these days, and rarely max it out, I don't use swap files. I have eight 4.0GHz processors. I run pipewire-jack usually at 256K buffer. While running a project I haven't really had any significant resource issues or "overruns" as we used to call them in jack. However when it's time mixdown the session using Rubberband I believe, which allows the project to be mixed faster than in realtime, that's when the processors may max out. But like I noted in the first post, this seems to be mostly an issue on these machines with processor No 5 running full tilt while the others are running around 75%.

I don't know if any of this is kernel related or not, because I'm not knowledgeable enough of about how scheduling actually works.

What I can say from monitoring this activity on HTOP, is that it appears that processor No 5 is filling up with kernel processes, and not necessarily audio processes.

I'm pretty sure a month ago I tried a mix in KLV-Plasma, and saw the same behavior. So like I said, I need to check whether I'm using RT-6.1.38.

This weekend I will try and explore all of what I'm describing here a little further.

I'm now thinking while writing this, that since Ardour is capable of assigning it's processor usage, if I exclude Ardour from utilizing processor No 5, then perhaps that would alleviate the problem, leaving that processor to handle only the kernel processes.

[rockedge]

I'm now thinking while writing this, that since Ardour is capable of assigning it's processor usage, if I exclude Ardour from utilizing processor No 5, then perhaps that would alleviate the problem, leaving that processor to handle only the kernel processes.

That Ardour can assign kernel cores is very cool and I'm interested if excluding cpu core #5 will elevate this unbalance. We'll have to look deeper into this and find what can be done to smooth out the CPU loads......

[geo_c]

I'm now thinking while writing this, that since Ardour is capable of assigning it's processor usage, if I exclude Ardour from utilizing processor No 5, then perhaps that would alleviate the problem, leaving that processor to handle only the kernel processes.

That Ardour can assign kernel cores is very cool and I'm interested if excluding cpu core #5 will elevate this unbalance. We'll have to look deeper into this and find what can be done to smooth out the CPU loads......

Yes, a few weeks back I fiddled around with the processor settings in Ardour, and after trying out several combinations I magaged to get a lot of distorted non-functioniong audio mess going, so I set it back to default.

More investigation necessary.

[Clarity]

I am in agreement with the both on you!

Kernels
But, with the 64bit PCs of the last decade, in both their silicon as well as the kernel ability enhancing applications management and scheduling, I am curious if a real-time element continues to any better at this juncture.

In dedicated workloads, such as what is done in "live" performances, and live mixings where the only significance of the workload is to honor the only real app, I continue to believe that a real-time may be necessary if the workloads on the mulitprocessors exceed 50%+ for extended periods.

Yet for general purposes of say multiple video feeds producing video captures while also watching a Youtube, or creating some documentation or running a VMs simultaneously, I've often wondered if overall behavior is better with or without a RT presence.

Just was curious.

On another note
One annoying problem I continue to have that I have never "seeked" a forum requested solution is the one with the I/O subsystem that is employed in the PUPs and other forum distros using ROX. When I start a long-running copy operation, ALL of the other ROX windows will "lock" until the copy completes (or is scheduler-interrupted) before anything in the other windows can be addressed. This is an annoyance that seems obvious but in appearance we (at least myself) just accepts it without question. Maybe time to question if there is some relationship with this I/O subsystem behavior that would also surface in other system uses.

[geo_c]

Yet for general purposes of say multiple video feeds producing video captures while also watching a Youtube, or creating some documentation or running a VMs simultaneously, I've often wondered if overall behavior is better with or without a RT presence.

This is something along my lines of thinking. If I were doing something like playing a virtual instrument in realtime, not connected to a network, not running anything but the necessary applications to run the instrument, I think a real time kernel might be the best scenario to reduce latency to it's absolute lowest. But when it comes to other audio and video applications where that kind of instantaneous response isn't necessary, it might make more sense not to be using real time scheduling.

I sense without any real evidence, but just my gut based on what I know about wayland and pipewire handling streams, that these frameworks might in one sense tend to throw a wrench in the real time scheduling and vice versa. It may be that pipewire/wayland would rather schedule the processing of streams and sync them with their own scheduling hierarchy.

ALL of the other ROX windows will "lock" until the copy completes (or is scheduler-interrupted) before anything in the other windows can be addressed. This is an annoyance that seems obvious but in appearance we (at least myself) just accepts it without question. Maybe time to question if there is some relationship with this I/O subsystem behavior that would also surface in other system uses.

I used to notice this a lot with older pups, but with KL's not so much, but the truth is I haven't fired up ROX for at least 6 months to a year now, except for maybe using Bookworm clean booted to install a bootloader or something.

I get everything file related done these days with Ranger, MC, and Xfe. They don't ever freeze other processes, and Xfe can handle multiple instances and copy operations simultaneously without issue. The other reason I use MC and Ranger is the ability to preview files easily, especially Ranger. That's a really productive manager once you know the keystrokes and capabilities and set up the configs properly.