I'm back at tweaking a 1.2Ghz Pentium M, into a capable DAW host.
This time I wanted to use newer Linux software. Things like Adrour 8, Muse 4, Wine 9, Carla, etc.
Last time I used an older Debian Linux (Squeeze), that had it's last update in 2016. The last backported Kernel was Linux 3.2.
These days, less and less of the mainstream Linux distros support 32bit machines. And the newer Linux Kernels tend to be a bit slower, on older machines (unless perhaps you can do a good amount of patching/configuring).
But I found a cheat. It seemed like Devuan, Alpine, and Void Linux were the best suited to my needs.
Alpine, built on, Musl C libraries, didn't yet have ports of the commonly desired audio software. But it is getting there. Alpine also needs a bit more care to configure. I'll be keeping my eye on Alpine Linux. But for now I needed something else.
I could have used either Devuan or Void, with almost equal advantage. I hadn't really explored Void much, so it got the green light.
So first the important stuff. When using Linux for audio work, you want some basic things.
1. Your kernel needs to have a "Real Time Premptive" or at least "Low latency" scheduler. You may suffice, with a standard scheduler, but it isn't always idea. Especially on older/slower machines. Void kernels are compiled with low latency, as default. I patched my kernel with the RT-Prempt patches.
2. Mitigations slow things down. So, disconnect from the Internet and turn them off.
The following kernel command line (added to you boot loader append or kernel line) disables mitigations for kernels before the 5 series.
"noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off"
I guess any kernal from version 5 and newer, only needs the "mitigations=off" command.
3. Older kernels use less memory and provide more responsiveness (lower audio latency, more processing headroom).
Void Comes with version 6, 5, and 4, kernels, in it's repository. If you don't want to compile anything, the 4 series kernels aren't bad. But I'm using a 1.2Ghz machine, so I went with a version 3 kernel. If you want to build older kernels, on newer Linux distros, you need to use a later version in the series. My old Debian Squeeze kernel was 3.2. It was too old to compile on modern GCC tooling. But version 3.18.118 compiled without a hitch. The only issue, using a custom kernel, is that you need to build your own "Initiation Ram Drive (initrd/initramfs)". It is a small filesystem, with the kernel modules (drivers), used to initiate the system. When you install from the distro repository, distro specific scripts run and configure everything for you. I used dracut, to build my initrd. Again, this is only a concern, if you manually install a kernel.
4. You user account needs realtime audio privileges. When you install the Jack Low Latency Audio server, any user in the audio group will have realtime audio privileges. So you just need to add your user to the audio group, if they are not already a member. Changes will not take affect until you re-login in.
5. There is a handy tool called RTIRQ, which assigns priorities to your IRQs. This is nice for giving priority to certain hardware. It is meant to be used with systems using the systemd initiation system. But you just need to put the rtirq.conf file in the /etc folder, and the rtirq.sh file renamed to rtirq and placed (with executable file properties set [chmod +X]) in /usr/bin or /usr/sbin (on Void Linux, its the same folder). Then put "rtirq start" in the /etc/rc.local file (without the quotation marks). The rtirq.conf file man need to be configured more, if you use USB/Firewire audio.
6. Don't install anything you don't really need; especially if it uses "running" system resources. For example, "Pulseaudio". It is a wonderful audio server, but it is a terrible friend. Its best to choose the leanest resource consuming program, for every task.
7. Disable all un-needed services and logging. With Void Linux, you can just delete symlinks to the service you wish to disable. For the running services, you can disable the executable permissions on the logging script (chmod -X filename).
When I finished setting up my system, it booted with 15-18Mb of memory used. After loading the graphical environment (Xorg), memory use was up to 48-52Mb. I also uninstalled all hardware firmware packages. My hardware works fine without them, but this isn't the case with all machines. I believe this freed up some of my memory. Seems ever kernel version increment adds 15 to 20Mb of more memory consumption. I thing with a 4 series kernel I booted to about 28-32Mb of consumed memory.
8. When recording live audio, the /tmp is a ram disk. Even in WINE you can configure you applications to use /tmp as a temporary folder for recording. When the files leave /tmp (or you reboot) your memory is returned to the system. Anything in /tmp is lost on reboot. Even on an old system, this pretty much kills recording issues caused by drive performance. The /tmp folder can be written in by any user.
I won't lie, this setup was not a speed demon. You wouldn't want to use Kde Plasma, Gnome, or Mate as a desktop environment. Something like IceWM or Openbox would be better suited. I was able to surf the web pretty well (for security reasons, keep in mind mitigations are disabled).
Windows applications worked pretty snappy, over WINE with WineAsio installed (included in the Void Linux repo). I had plenty of headroom for Vst/i plugs. Latency was pretty low, considering the system specs. Most Windows applications were happy with a buffer of 128 with 3 periods or 256 with 2 (Jack Audio Connection Kit).
Linux applications were happy with the same audio latency settings as above. Qtractor has some QT UI sluggishness loading certain windows. But it otherwise performed well. Arduor was fine and usable. Muse was a little disappointing. It worked fine, but the internal plugins crashed the application. Everything was fine if you didn't use them. I thought about testing a downgraded version 3 or 2.2 (if it would build). But there are only a handful of internal plugins, and other than the Soundfont player, I don't use them. This is probably just a problem with Void's build. I tried it on different machines, and the crash (segfault) was the same. I do wonder if there is some missing dependency I've not installed. More than likely, it is just the build itself. Carla works outstanding. Because Carla's UI is built with QT, it is sluggish. But only when loading new windows. When the UI is not being used (configuring plugins), there is no lag from using Carla as a plugin and patch host. DSSI-VST works fine. As always, I often use EnergyXT 1.4 as a VST host on top of DSSI-VST. Some VSTs just don't work well directly on top of DSSI-VST. It can get a little weird loading Carla, then EnergyXT; but you only need to do that with Linux applications that don't support DSSI plugins.
The Gem of this experience was using the Linux version of EnergyXT 2.7. Without Carla (My older Debian install did not support Carla), EnergyXT on Linux seemed pretty worthless. It can load soundfonts and samples, but only Linux VSTs. There are not a good supply of Linux VSTs, especially for a 32bit system. Further, EnergyXT only supported VSTs, not DSSI, LV2, LADSPA, etc. So none of the other Linux plugins did you any good. Since Carla support being loaded as a VST, EnergyXT 2.7 can breath a whole lot more. You still need to patch it to work with Jack, instead of Alsa, and the Jackass plugin if you want midi out. But on this 1.2Ghz 1.5Gb machine, EnergyXT 2.7 is the most performent, and very stable.
I was also surprised by how well the Windows Applications ran. Many ran better than they did with Windows XP, which is what this machine was designed to use. And applications that would not run on XP can run here. But there will always be some applications that do not run in WINE. I haven't tested ones like Sonar (Sonar hasn't worked on WINE in the past). I could easily use a Windows application to score out a groove.
