I’m down a damn rabbit hole today.  I have a Raspberry Pi 4 B,

an Audioinjector Stereo HAT:

a Novation Launchpad,  We’re going to save this part for another day.  The Launchpad shows up as the first device, and the audioinjector setup scripts don’t like it when the audioinjector HAT isn’t the first device.

and Windows 10 running the Debian distro under Windows Subsystem for Linux.  

This got going because I was so terribly impressed with the Empress Zoia:

This little stompbox is essentially a modular synth powered by the Puredata programming language, a nodey-gui way of constructing audio pipelines and processes.   I really want one, but I don’t have $500 to shoot out my hindquarters right now, and all I really want is a decent hardware reverb, delay, and distortion unit that I can use on an FX Send in my hardware mixer.  This is part of the DAWless journey, in which I attempt to get out of the desktop for music. 

The first part is easy:  If you have Windows 10 past build 1803 or so (and you should), just get Debian from the Windows App store.   If you have a Mac, you can use your terminal.  If you have a linux machine already, you don’t need me, you already know how to get the packages the system complains about not having.    In any case, setting up some kind of command line to connect to your Pi is dead easy. 

The fun begins when you try to use your Windows Debian install as a development platform for the Pi.  This series isn’t going to be a how-to on how to set up a Pi dev environment on Windows Subsystem for Linux, or a step-by-step walkthrough on configuring a Pi for audio, but more of a place where I can write down the links to other guides and how-to’s that worked for me.   And because this stuff is moving so fast, any specific instruction will be rotten to the core in a couple of years, so I’m not going to bother.  But it breaks down like this:

—Set up WSL if you’re using Windows for basic bash shell: I’m using Raspbian Lite on the Pi, so it makes sense to use the Debian system for WSL… For now.  On install of the Debian app, I set the linux user to be “pi,” which is probably terrible security, but it’s convenient.

—Set up your Pi with ssh and wifi –  As minimal as you can go.  I used Raspbian Lite, which still has  a lot of stuff on it, but I’m not ready to make a custom Linux distro yet.  You can skip WiFi if you want, but the Pi needs to be near the music gear and I need to be in various places around the house when I’m working on it.  When I set mine up, ssh was not installed or enabled in Debian on Windows, and there was some post or other that said the WSL ssh install needed to be purged and reinstalled via apt-get, but I can’t find the link right now.  So basically: sudo apt-get purge ssh, then sudo apt-get install ssh.  You’re going to become very, very familiar with the apt-get command if you aren’t already.

–Set up X11 display: The link is a little dated, because Microsoft has been enabling more and more standard Linux-type things in WSL, but graphics and audio are still not natively integrated.  Solution:  run an X-Windows server on Windows to handle the graphics from your linux executables!  This is awesome.  But as someone who grew up on Silicon Graphics workstations, yawn.  All I can say is it’s about damn time.

–Set up PulseAudio for Windows and WSL: This post is assumes you’re running Ubuntu-bash in WSL, not Debian-bash, but it should work the same way.  This is how you will be able to audition your Puredata patches before you ship them off to the Pi.  NOTE: WIP.  I think this going to shit the bed when I try to tell PulseAudio to use my RME Fireface 400 as the audio device.  EDIT:  Couldn’t get this to work.  Change of plan.

–Set up your pi to use your Windows machine as its X11 display:  This is where it gets really bonkers.  Assuming you successfully bring up an Xserver on Windows, you can then forward the pi’s X11 display to it.  We care about two things: Puredata audio on the Pi and the ability to noodle patches on Windows, then save them to the Pi.  So all of this convoluted shite is actually worth it, because a pure X11 connection is a lot cleaner and less crufty than RDP/VNC, and even “lightweight” desktop GUIs are fat bastards.   The magic is in the section on Advanced X11 Forwarding. So what’s happening is that Windows is running an X-server, waiting for connections.  it gets one, from WSL/Debian, where the DISPLAY=localhost:0.0.  Because your instance of Debian has X11 forwarding, we can use ssh -Y pi@10.0.1.200 (our Pi IPv4 address) to enable a trusted X11 connection back to your Windows X server.   When you run Puredata, the dirt-simple Pd GUI opens up in an X-window on your Windows desktop.  So let’s move on to audio.

Before you do, though, set these lines in /etc/ssh/sshd_config on the pi:

X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost no

This keeps your remote display from colliding with the one on your attached monitor, if you have one.

If you’re using Visual Studio Code (and this hung me up for a long time), you have to set the display environment variable in launch.json:

"env": {"DISPLAY": "raspberrypi:10.0"},

Put this in the configuration you’re using to debug, where “raspberrypi is replaced with whatever you named your Pi, if you did .

–Configure the AudioInjector HAT.  took me a minute to figure this out, because it definitely does not Just Work. First, the audioinjector.net page for this device makes no mention of the github page where the actual instructions are stored, so you have to find that on your own.  On the main page there are links to the flatmax.org forums and the Audio-Injector github repo, where you can get the info you need.  Even if you do everything right, it’ll probably bark at you about the sox package not being installed (sudo apt-get install sox) and there’s a scary message about only updating firmware on the advice of an engineer.  Do it anyway.  Then run the tests.  You won’t get the nice graph and spectral analysis the instructions show you unless you install gpicview, but if you do, and the X11 stuff is configured correctly, it should plot the test results in an X-window, which looks like this:

–Install Puredata on your Pi.  This is a simple sudo-apt get install puredata command, and it should go fine.  At this time, the standard package available is 0.49, but if you must have the latest, download the debs and install them.  Start Puredata, and run the audio tests.  

So at the end of the day, I have something.  Pd running on Pi with a vanilla freeverb patch loaded, and I can actually send stuff to it and get something back, but there’s a gnarly feedback loop I need to figure out.

The Audioinjector Stereo card has a nasty tendency:  It forgets about its routing between power cycles, so you have to remind it to use the RCA inputs, otherwise it defaults to the mic.   To kick it back into gear, it needs the setup script for RCA to be run again:

alsactl --file /usr/share/doc/audioInjector/asound.state.RCA.thru.test restore

That’s all one line.

I’ll post a demo video as soon as I get some sleep.

A note on ALSA and JACK: Alsa and jack are still a little mysterious to me.  They’re designed to give you ultimate control over how audio on your Linux machine works via the use of config files, which means you can really tweak your internal routing and soundcard parameters.  For someone with no familiarity with Linux, this whole thing is a learning curve made of learning curves.  But if you’re going to mess around with linux audio, it’s a good idea to get familiar with what’s going on with these two elements, because every guide you find will mention at least one of them.  Right now, Puredata is hitting the hardware directly, which is fine, I don’t even have JACK running.