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.