Recent | Online | Vintage | Modern | Win | Mac  OS9 | DOS | Amiga | Atari ST | Graphics | Midi io | Sequencers | Roland "MC" | E-mu | Ensoniq | Akai MPCs | Samplers | Akai "S" | Roland "S"Synths | VST Samplers | VST Synths | Roland "JV" | Modules | Drums | Mixers | Timeline | HackintoshArtists | Graphics

Welcome to Oldschooldaw.com! (Online since 2014) proudly SSL-FREE! and serving vintage computers worldwide! if you are human, Register & Login to gain more access to all boards here; Some guest permissions have been limited to reduce traffic from bots and encourage registration. This website serves as a home base for any and all peoples who are interested in the topics posted here which is mostly very technical references + resources to do with music production on various home computer operating systems. If you have any information that is relevant, we'd love to have you take the initiative to contribute!

Author Topic: Patched together Linux, for older 32bit machines.  (Read 3088 times)

0 Members and 1 Guest are viewing this topic.

Offline dawful

  • Jr. Member
  • Posts: 87
  • new to the site
Patched together Linux, for older 32bit machines.
« on: July 10, 2024, 03:16:44 AM »
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.

Offline dawful

  • Jr. Member
  • Posts: 87
  • new to the site
Re: Patched together Linux, for older 32bit machines.
« Reply #1 on: July 11, 2024, 02:54:59 AM »
I forgot to mention, the RTIRQ service can be use with a non RT-PREMPT patched kernel; as long as the kernel isn't a version before the 3.x series. But the kernel cmd line "threadirqs" must be used. Then a regular or low latency kernel will be able to use RTIRQ.

This thread is more useful to someone that already knows a little bit about installing and configuring Linux. Someone, starting out, would likely need to google more details on some of the things I've mentioned. There are always little bumps in the road, with these sort of things. For example, Void Linux includes WineAsio (in the package application repository); but Devuan and Debian do not. So then WineAsio sources would need to be downloaded and compiled manually. It is trivial to do, once you know your way around, but a bump in the road none the less. These things should be considered, before diving in. If you are new to it, it would be a project to take some time with. Something to slowly hack way at.

I should also mention, that this thread was directed at getting more power, out of old machines. Also, providing an alternative platform, for older (and sometimes newer) Audio applications. This being an alternative to installing an older Windows OS, giving life to an older machine, destined to run your favorite older app (WINE compatibility [and perhaps hardware] as a the main conditions to success).

But if you already have plenty of power, there are Distros designed specifically to work with Audio production. In the case of a newer machine, the only reason to follow any of the advice here, would be to squeeze more out of said workhorse. But things like "using an older kernel" may actually work against you, as newer hardware drivers may not be included in them. Might be good to examine when the kernel was released, as a basic metric when comparing to the release of your hardware. My laptop was released in 2005-2006, so I was very well covered.

If there was actually any interest, I could do a step by step guide. It would rely completely on the Void repository, no custom Kernel builds, or anything like that. But Void Linux does have a pretty good "Hand Book" on it's website (also included on the system as part of the documentation). Beyond that, most things not included in the "Hand Book" are common to most Linux Systems. So a guide from me would be a little superfluous, but I would be willing. Sometimes google just doesn't always fill in the gaps, before you run out of steam.

Offline dawful

  • Jr. Member
  • Posts: 87
  • new to the site
Re: Patched together Linux, for older 32bit machines.
« Reply #2 on: July 14, 2024, 03:47:09 PM »
If after some experimenting, I feel like its a workable and useful setup, I intend to make a LiveUSB Linux for 32Bit machines. The aim would be to primarily run 32bit Windows DAWs and VST/I over WINE and WINEASIO. If the machine had enough memory, for recording live audio, the machine wouldn't even need a hard drive. Through the use of a "live union filesystem (AUFS)" the LiveOS would be very capable towards customization, per user needs, or a default setup could be used/demoed.

Most typical desktop tools (archivers, editors, browsers) would be Win32 applications (download and installed, by the user). Only the very basic Linux tools (mounting[iso images, usb drives], network configuration, disk partitioning) would be available, with the ability to install more.

The project would be fairly useless, to a seasoned Linux user. But it might be nice, for a user not interested in learning all things Linux. The Linux world has lacked a project like this, for a long time. But that is because most people could do it by learning Linux. The particular scenario here, is aimed at being fitted for older machines. It skips the steps required, for those non Linux Gurus, to provide a "usable" experince; as default modern installs crawl on old machines.