Why is it so hard to get DAW software right on Linux?

There are many magnificent people doing great work on Audio in Linux, but the whole eco-system for Audio production, by which I mean, people attempting to work with and to develop Digital Audio Workstations, Virtual Effect and Instruments Plugins (using the VST format, or some other similar plugin architecture) and other similar software, have found is a very difficult thing to get right, and very easy to get wrong.

Neither PulseAudio nor Jack are the right solution for DAW users, and there really isn't a unified audio API solution for Linux that really does what DAW users need. Recently I ran into an excellent podcast interview with the lead developer of Ardour, which is an amazing free/libre open source Digital Audio Workstation.  I recommend listening to it:

http://libregraphicsworld.org/blog/entry/podcast-ep-003-paul-davis-on-fixing-big-linux-audio-issues

I'm keeping a bookmark around for the "libregraphicsworld.org" site because it seems like a fantastic resource.  The podcast is available in audio format plus a transcript.  The whole thing is recommended, and I'll assume you've read it, or that you don't care, and will not reproduce its content.

What I want to comment on is one aspect of what Paul Davis says.   If I was going to contribute to an open source project in my spare time right now, Ardour is one project I would definitely be interested in helping with, but also, I would like to increase the number of high quality VST audio effects, instruments, and other plugins for Ardour and other DAWs that exist.

What I want to do is attempt to conceptually map the problem.

Unrealistic GOAL:   How could a Linux box become as useful as a Mac, for professional audio?  Feature parity with, say Cubase 10 Pro with its pitch correction and production features, plus Izotope RX8, plus say, something like Komplete 13, with its hundred-gigabytes of multi-sampled pianos and strings, and world class effects and instruments.

Altered (Semi-Realistic) GOAL:   How could a Linux box become almost as useful as a Mac, for professional audio, for at least some people, especially people who don't have the money and can't afford Windows or Mac and commercial DAW and VST offerings?

What is needed:

1.  Top tier driver support for specific audio interfaces from RME,  Arturia, and about 200 other audio interface manufactures. Not just some generic class compliant drivers.

2. Full support for onboard DSP processing resources that live inside these audio interfaces.

3.  Really great thunderbolt, and modern USB performance.

4. A realtime friendly Linux Kernel which does not introduce latency.

5. A complete set of tools to find out where latency is creeping in and make it possible to reduce and remove those sources of latency.

6.  Reference Audio grade realtime performance comparable to Mac OS X.

7.  Some Move Towards Feature parity.   I think the most critical thing is a reference quality sampler platform, something that is open source but which can replace Falcon, Kontakt, and Halion as an open source sampler VST.  Are open source people going to build a really high quality free Piano sample library? Even if the VSTs become free for high quality sampler VSTs, will multi gigabyte piano sample libraries ever be free?  After that need has been addressed, I believe decent mastering tools, and good pitch correction tools will be the next biggest thing that the Ardour-on-linux DAW user will miss.

Considering the value proposition of Linux in 2020, in the professional audio world is like considering vote share in 2020, for a third party candidate in the US election. It's not even funny.  There's Mac, and there's PC, and then, there's (for home hobby toy use), Linux.  That's just not changing.

Meanwhile, I believe that folks like Paul Davis and the rest of Ardour team are doing amazing things and I plan to help out where possible, and when I have some time.

Other AMAZING open source things are happening. There's the VCV RACK.
There's MOD DUO, there's the JACK project.  Want to build an open source effect rack system or guitar pedal, with full featured delay and reverb processing, running on a raspberry pi?  The open source world has got you.  There are many really interesting sounding VST instrument plugins too,  although you can build your own audio and instrument plugins, really, with VCV rack, and a bit of dragging around of some virtual audio cables.

The future of AUDIO on Linux is going to be amazing. the future of DAW software, maybe slightly less amazing.

The thing is, maybe Ardour (with a supported interface) is going to be great.     Once Ardour, and Mixbus (which is based on Ardour) get VST3 support, Ardour on Windows and Mac will be become interesting again.  

A Year of OpenSUSE Tumbleweed VM based Software Development, and thoughts on Security

I have now been using OpenSuse's Rolling Release (evergreen) Tumbleweed repositories for over one year.

I would like to reflect on a few things that I have learned.  First a bit of a backgroud on my Linux user history. 

My first Linux distribution that I used seriously in any way (as anything other than a toy) was Red Hat (not Red Hat Enterprise),  Linux version 5.0, in 1997.  I made some efforts to use Linux before that point, starting with Yggdrasil Linux back in about 1995 but did not achieve much success getting anything working that I would want to use as a daily working environment.

Just as modern RedHat/Centos and similar (OpenSUSE) distributions do today, it used the RPM package format..  In these early days you would install from one or two or three or four 650 megabyte CDs, and some people, in even earlier RedHat Linux days, installed from 1.44 meg floppy disks.   Just as now, Debian also existed, and the fork in the Linux world between ".deb" package and ".rpm" package systems was already well entrenched.  Ubuntu did not exist in these early days.

An early focus in Linux in the 1990s was in trying to get your X Window desktop system to work as smoothly as Windows did, on equivalent hardware.  The early desktops from that era were mostly trying as hard as possible to emulate Windows 95 or Windows NT, then the dominant Microsoft desktop operating systems.   Configuring networks (wired only, mind you, wireless networks weren't a big thing in 1995) was often confusing and annoying.   RedHat was one of the first I used that made getting a client PC's network connection (DHCP)  and connecting to the broadband and dialup internet connectivity options of the day, reasonably easy. Back then, SuSE linux also existed. 

Tumbleweed, the subject of this post, really is the bleeding edge version of SuSE in 2019, almost 25 years after I first started using Linux, many of the same challenges from 1995 remain. They are:

1. My professional work remains centered in Windows.

2.  Linux is a bit quirky to get working and you still often need to get good at editing configuration files, even in 2019.  And you certainly need to be good at reading logs and googling error messages.

3. Video cards are a shit-show in Linux, and this is the fault of the video card makers, not Linux.

4. Professional grade Audio workstation tools remains mythical creatures, more or less, in Linux.  I'm not talking about making your audio drivers work well enough that you can watch youtube on Linux, I'm talking about professional audio interfaces, and professional audio production work in Linux.  In 1997 the problem was getting your soundblaster to work properly. In 2019, the problem is that Windows and Mac are suitable platforms for VST instruments, DAW (Cubase, Protools, Etc), and other things.

However, one huge difference for me is the presence of free, open source virtualization platforms like QEMU/KVM, and the way that this allows me to run not just one but several Windows editions on my workstation (a big dell workstation class tower machine), with 64 gigabytes of memory.

I would like to note that aside from the flaws of Linux in various vertical markets (including audio production and 3D video driver performance for products like CAD/CAM), for most regular desktop and most regular professional software development duties Linux is incredibly capable.

During this time since 1995, something else has radically changed.  Security concerns.  Windows remains in my opinion a giant target, a great big red target that all kinds of people are trying to penetrate and get past.    In my opinion, running Linux puts you far ahead of the curve. Because only a small percentage of the population of computer users runs Linux,  it's not yet worthwhile for most hackers to specifically target Linux.    Note that Spectre style exploits, that rely on the actual architectural flaws of modern superscalar CPUs are a risk and a concern on Linux at least theoretically, the thing is that since Linux kernel memory layouts are different than Windows, and there are no stable ABIs that malware authors can target, the presence of a Spectre style exploit on an AMD or Intel CPU alone, does not result, in linux, in the same level of difficulty of building an actual exploit that could, say, lurk in the background and read your banking details while you browse.  I know someone's going to say that "obscurity isn't security", but obscurity is difficulty, and it's something.

I personally am going to continue running mostly in OpenSuse Tumbleweed and running Windows in a VM.

The most important platform attribute for professional software development are performance,  stability, and security.   For those three attributes, Linux is kicking Windows to the curb for me. Windows is not something I trust to give root level control of my computer.

Audio on Linux is a Disaster, Debian Stretch Edition

I have recently learned more than I wanted to know about how Audio works in Debian Stretch Linux, and yet, not enough to solve the problems I have.

Generally I love Debian Stretch Linux,   the two big pain points are, Audio, and nVidia.  And nVidia is not Debian's fault, it's nVidia's fault. I hate you nVidia, did you know that I hate you? Anyways back to ranting about audio.


Here are my problems, stated in as transparent a way as I know how:

1. I need to use Skype for work, and a few other closed-source conferencing and remote desktop sharing apps, including join.me, and GoToMeeting.

2. Built in Linux desktop apps like Sound Recording apps all work fine. If they were not working I could investigate them down to the source code level to see why they don't work.

3. But commercial closed source audio-aware apps do not work in a consistent way. Skype for Linux these days is some heinous Electron app.  It probably talks to pulse-audio.  So does GoToMeeting, so does Join.me.

4. On Skype, people say I sound like a chipmunk. On Join.me I sound like a monster or a robot. Many issues like this have to do with sample rate configuration options.  How you can find a set of options that work for all the various apps you have, is an impossible problem.

If I could make an analogy, it's like going into a dark room, and there are an array of 100 or more light switches. One of those combinations of 100 switches, say, 36 of them on, and 64 of them off, in some combination, out of a possible of 2^100 combinations, will result in the lights going on. Another combination, also probably having to be found by trial and error will result in the lights going off. Other combinations will result in your hair catching on fire, your dog being decapitated, and your kids voice changing randomly from sounding like Obi Wan Kenobi, changing to R2-D2, and then to Chewbacca.

In between changing combinations of lightswitches, you should google a bunch of stuff, make notes, try things, and see if you can find the working combination.

I don't see a solution here, because I don't see that there's a standard way for Linux apps, either real native closed source ones that don't use electron, or for electron apps, to work on every Linux distro out there that has Pulseaudio as its audio subsystem.  Perhaps all these apps are tested, and developed, and work on Ubuntu, but not on Debian or any other Debian derivatives.

Who really knows?

Thinking about Starting a BSD Blog

This blog has been kind of inactive, but I've been playing around with a lot of things which are Unixen but which are not Linuxen in the last year:

* Illumos, SmartOS and OpenIndiana (stuff based on what was once OpenSolaris, a now dead project)

* The BSD family (FreeBSD, OpenBSD, and others). Most recently I've been messing around with TrueOS which used to be called PC-BSD, and before that I spent some time messing around with Dragonfly BSD.

Whenever the BSD folks talk about Linux licensing, and the GPL, I have to admit, I see their point, and I also see some of the points that Richard Stallman and his Gnu Purists point to.

Where I think the BSD people are undeniably right is:

1. You can't afford to lawyer all the GPL violations in the world, and can't technically even detect them, and so the question is, do you want to spend your time on that?

2. It's fair to ask the question, why not let people take stuff closed source.   If they want to fork and close source a project, why not let them?

3. It's fine to just not care about software freedom, and just want to use your computer.

Where I think the Linux people are right is:

1.  Software freedom leads to hardware freedom.  I don't think that the BSD approach is the right way to handle companies like nVIDIA that refuse to open their drivers. Having the GPL there and the problem of tainting your kernel with private non GPL garbage, is exactly how I think the Linux kernel should be handling it. It's not just a problem that the nVidia partially binary driver is a stupid thing because there are no Stable ABIs in the Kernel Space, it's also a problem because it's a binary blob in my computer and I don't want any binary blobs.

2.  Principles are worth making a fuss over.

So that's where I sit.  BSDs are cool. Linux is cool.

Building Python 3.6 from Source on OpenSUSE like an idiot

Recently I was humbled to find out that I am less good at building things from source than I used to be.  Let me state first that what I am doing below is not something most Python users should ever want to do.  On OpenSUSE and other Linux distributions, we install our software using packages. That's your normal first way of getting python.

Your normal secondary way of getting python, and something a lot of serious python developers do, is use pyenv, which is similar in nature to the rbenv tool ruby developers use.   Both installing system distributions of Python, and installing your own local python with pyenv are generally recommended ways of getting python on Linux and unix systems.

This way I'm showing is generally NOT recommended.

Enormous things like Python are not normally manually built from sources by most users, on most common Linux distros. If you're one of those Arch-style linux or other source-driven-linux distributions, or if you're a FreeBSD-style ports BSD unix user, you're probably more used to configuring and installing things from source.  The instructions below took me a long time to figure out.

First, I have to admit that I did something really stupid. I installed directly into /usr. Never never do that. That area of the filesystem belongs to "openSUSE package management" land, it's a "system folder".   There is no "make uninstall" in python or in any other common C and unix classic "configure+make+make install" source "tarballs".

The sensible thing to do is use a prefix like /opt/mypythonjunk, which I have chosen in the example below. Then you can wipe (rm -rf /opt/mypythonjunk).

After the obvious thing (download the tarball and unpack it, cd into that directory containing the source code, here are the configuration and build steps I used.

You need some stuff installed on your computer. I'm not able to make a complete list but it includes all the developer basics, gcc,make, binutils, etc.  You also need the "dev" (devel) packages which include the libraries and headers for things.  On opensuse that means "zypper install ncurses-dev", and similar things. You must install all that stuff before you can build from sources.

I was working from ~/python/Python-3.6.0  but you can work from anywhere you like.

make clean

mkdir  -p /opt/mypythonjunk

# --enable-optimizations might be useful for some real world uses.

# --with-pydebug might be useful for some development and test uses.

./configure --with-pydebug --enable-shared --prefix=/opt/mypythonjunk

for m in _struct binascii unicodedata _posixsubprocess math pyexpat _md5 _sha1 _sha256 _sha512 select _random _socket zlib fcntl; do 

    sed -i "s/^#\(${m}\)/\1/" Modules/Setup; 

done

make

sudo make install

sudo ln -s /opt/mypythonjunk/lib64/python3.6/lib-dynload/ /opt/mypythonjunk/lib/python3.6/lib-dynload

When you read the above, translate /opt/mypythonjunk to /usr mentally in your head, and imagine the mess I made when I did that. Be smart. Don't do that.

There are instructions on Python's web site. Read those.  But they're not enough for some distros, and OpenSUSE is one of them.

The initial make clean thing is pretty standard advice in case you ran a previous build and your working copy is dirty. It's harmless if your working copy isn't dirty. 

Next, I'm making a single output folder to contain all installed stuff.  I'm configuring with a few flags that I discovered are useful in various cases, and I'm specifying where the installation target folder should be.

The for m... part is something that someone on IRC pointed me at, which is really a nice way of telling you that you need to edit that file Modules/Setup;  the edits above appear to be enabling some of the optional Python modules you might want or not want.

If you run make it will work, but if it fails in some bizarre way, try again with more verbose output ( make -p or otherwise), and save your logs for later analysis.   If you want to ask a question on #python on irc, you will want to paste your make output logs into the python channel's own pastebin service.

 Something that surprises me during the make install phase is to see a lot of gcc (compilation) and tests being run (re-run? recompiled?). I'm told on the IRC #python channel that this is due to something called PGO (profile guided optimization). It should occur if you used --enable-optimizations during the configure phase.

What tripped me up was that the python binary installed and ran and could not find readline or any other python core modules.  The ln -s line above is the fix for that, and it took two days of scratching my head to realize I should do this:

/opt/something/bin/python3.6

import sys

sys.path

Hopefully obviously the path I put above is not the correct path for you. That's a hint to put your own actual direct fully qualified path name in python.

Then look at the output above, and find what directories it's searching for, then go see if those directories exist. If not, the thing to do is either edit sys.path (no thank you!) or hack it (yes please!) with the symlink command (ln -s).

Another trick I find helps to get a recalcitrant python to start up is that you can force a PYTHONHOME value for one command:

PYTHONHOME=/opt/something /opt/something/bin/python3.6

And yet another fun trick is to start python up without installing it, like this:

LD_LIBRARY_PATH=/home/wpostma/python/Python-3.6.0rc1 ./python

I hope these tips help.  I'm posting it on my blog so that the Mighty Google will index it, and other people who are as frustrated as I got trying to get this work, might get additional tips.  Corrections, and suggestions are welcome.

O'Reilly Book Bundle!

There's a pretty awesome pay-what-you want sale over at Humble Book Bundle, featuring O'Reilly Unix books.  One of my all time favorites, which I own in original dead-tree version, Unix Power Tools, is included if you pay $8 or more.   If you pay $15 or more, you also get some pretty awesome networking tomes, including O'Reilly's excellent TCP/IP and DNS/BIND books, and a couple more.

I really can not recommend the Unix Power Tools book enough, so I'll just cover a few reasons why I think everyone should read this book, even though it was last revised in 2002. It remains a fantastic tome, and well worthy of reading.

Three top reasons to read it:


1.  It has the best written explanation of the zen of Unix-like systems that I have ever read, the composability paradigm, and the sometimes baffling array of choices you have, such as between various shells.

2. It covers most of what you need to be a competent user, developer, or system administrator on Unix-like systems, Linux or otherwise.

3. It will get you started in a hundred different things, whether it's awk or sed, or vi (lately vim), shell scripting, or the myriad of standard utilities for finding things (learn when to use find, when to use grep, when to use locate/updatedb, and others) and so many more things.

This was the book that taught me enough that I started to actually grok the unix way. Before this book it was a random walk through chaos and entropy. After this book, it was still a random walk through chaos and entropy, but with a wry smile and a sense of understanding.

Even if you think you're a Unix expert you'll learn lots from this book. It's been taken down and thumbed through dozens of times, and I've read it cover to cover twice. Go grab it!  And give the fine folks at O'Reilly some love, tell them linux code monkey sent ya.


Update: If you're one of the millions of people who was happily working away in your Windows only world, and then someone had to go and bring Linux into things, and you are expected to learn how to just SSH into a wild Linux boxen and remotely deal with it,  and that is something that scares you, there's a book in the bundle that starts exactly with installing Putty on Windows and learning what to do when you get into the mysterious world of that bash shell in that remote Linux system that you now have to learn, and may even learn to enjoy.  If this sounds like you, check out the Ten Steps To Linux Survival title in the Unix bundle above.

Upgrading OpenSuSE LEAP 42.1 to 42.2

For some reason I can't find this documented anywhere in a step by step set of instructions that only apply to LEAP 42.1 to 42.2.  The SuSE docs are good but they have to cover a bunch of versions and a lot of edge cases.  So, since this is the web, I puzzled, googled, puzzled, and then tried stuff.   It worked, and it's pretty easy, actually, but seemed strange to me as I'm more used to Debian and Ubuntu, and Fedora.

It seems odd in 2016 to have to use sed to modify a text file, so you can update from a major release of OpenSuSE to another. But you could also edit the zypper repo file by hand, if the following seems too convenient and easy.   Ubuntu  and Debian are a bit friendlier when it's upgrade time.  I was kind of floored that YaST didn't have a "new OpenSuSE version detect/upgrade" menu.

Before starting you should check your drive space and clean up any old snapshots using snapper.  If your system has btrfs as the root filesystem type, I suggest making sure you zap old snapshots until you have at least 12 gigs of free disk space.  You can not believe the output of df if you want to know your real free space on SuSE Linux systems with btrfs, use this command as root:

btrfs filesystem show

Note that it doesn't show you your actual free space, you have to do a bit of mental math, in the example below, there is a little less than 10 gigs free, approximately, probably enough for your upgrade to work.  I always like to have 12 to 15 gigs free before I do any system upgrade, so the situation below is borderline to me:

Label: none uuid: b3b42cba-c08e-4401-9382-6db379176a1f
Total devices 1 FS bytes used 90.21GB
devid 1 size 100.00GB used 85.29GB path /dev/sda4

On the same system above, df -h might report the free gigabytes to be much higher than that, and that is why you can not trust df, it doesn't work right with btrfs.  And to make life even weirder the command btrfs filesystem df /  where df (disk free space) is in the name of the command does not actually report free space, only total and usage.  Sometimes I really want to reach through the internet and ask the authors of tools what were you thinking?

There is a way to get actual free space from btrfs, which is this:

btrfs filesystem usage -h /

Besides giving me the unallocated free space in gigabytes, it also gives me a lot of stuff I don't care about.

Also before starting, make sure your system is up to date (zypper dup) and then list your zypper repos (zypper ls) and disable any that are third party. I disabled google-chrome before upgrade.

I also have a personal habit of archiving my entire pre-update /etc, with tar. (sudo tar cvf /root/etc-backup.tgz /etc).

 As root the system upgrade commands to go from 42.1 to 42.1 is:

sudo sed -i 's/42\.1/42\.2/g' /etc/zypp/repos.d/*

zypper ref

zypper dup

Further decisions/actions may be required, usually involving selection of packages to be de-installed, to avoid broken system. For example:

Reading installed packages...

Computing distribution upgrade...

2 Problems:

Problem: libkdevplatform8-1.7.1-1.3.x86_64 requires kdevplatform = 1.7.1, but this requirement cannot be provided

Problem: kdevplatform-lang-5.0.1-1.1.noarch requires kdevplatform = 5.0.1, but this requirement cannot be provided

Problem: libkdevplatform8-1.7.1-1.3.x86_64 requires kdevplatform = 1.7.1, but this requirement cannot be provided

  deleted providers: kdevplatform-1.7.1-1.3.x86_64

 Solution 1: Following actions will be done:

  deinstallation of kdevelop4-plugin-cppsupport-4.7.1-1.4.x86_64

  deinstallation of kdevelop4-4.7.1-1.4.x86_64

  deinstallation of kdevelop4-lang-4.7.1-1.4.noarch

 Solution 2: keep obsolete kdevplatform-1.7.1-1.3.x86_64

 Solution 3: break libkdevplatform8-1.7.1-1.3.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c] (c): 

I chose     1   whenever given a choice like the one above because I am pretty sure I can live without some bit of stuff (kdevelop and its various bits) until I figure out how to get it back installed and working.

Next I get to the big download stage.  I have to read and accept a few license agreements (page through or hit q, then type yes).

2307 packages to upgrade, 27 to downgrade, 230 new, 11 to reinstall, 89 to

remove, 4  to change vendor, 1 to change arch.

Overall download size: 1.98 GiB. Already cached: 0 B. After the operation, 517.6

MiB will be freed.

Continue? [y/n/? shows all options] (y): 

After all the EULA dances, it's time to get a cup of tea and wait for about 2 gigs of stuff to download through my rickety Canadian cable internet.

Next post will be on the joys of what worked and didn't work after this finishes.

Post-Script:   Everything seems quite stable after upgrade. The official wiki docs on "System Upgrade"  consists of a series of interleaved bits of advice, some of which apply to upgrading from pre-LEAP to LEAP, and some of which generally still apply to 42.1 to 42.2 LEAP updates.   On the SUSE irc chat, Peter Linnell has informed me that starting in Tumbleweed there is a new package to make this process easier called yast2-wagon.