KBLsystems Audio Lab

Fighting long boot times when using older RPI

It has been quite a while when did my 'audiophile' music player built.

It has been almost a decade now and there is a zillion of dedicated distro's around to make this really easy.

Just google: RPI musicplayer.

All really nice and slick..but..taking..ages..to..boot, certainly on older PI's

So while reviving this old project to include a transformer balanced output, (driven with a class A running NE5532! ) I worked myself through the big pile of clogged info to get a faster booting system.

Now the easiest way would be to get yourself a custom build image using a build system like buildroot, yocto, openwrt.

I did have a go at all of them but the easiest way to get yourself (like me total noob) going would be to start off with buildroot.

Just follow the walk through (maybe add in a SSH client like dropbear) and you will quickly get your own fast booting image. That is: it isn't complicated but the compilation takes hours!

The bit more nasty part comes when you want to take it further: not many people talking about this, so for future reference here's some reminders.(as long as this will be of any value in the allways changing wonderful world of linux 😂)

RPI has it's own rather special way of booting at which time you can configure all kinds of hardware add-ons by using so called dtoverlays.

If you have been working with RPI and audio you will have come across these: to configure edit the config.txt file in the 'boot' partition of your disk image. (sometimes it will have just a number instead of the name 'boot')

For a first test add 'dtparams=audio=on' to this file. This will select the onboard shitty audio out. In theory. But the inner workings of linux in these buildroot-builts don't seem to be loading the necessary kernel modules. Something with udev and dts / dto. Complicated stuff. Tell us when you know how to do this!

I got it working with 'modprobe snd-bcm2835'.

We did select the packages to get alsa and other obvious stuff like mpd, mpc and a texteditor in our simple build, right?

Now to play some music (from that USB stick) you will have to mount it first: 'blkid' will give you a device name or UUID, create a mount point and mount. Configure '/etc/mpd.conf' to point to that music directory and also add a default alsa-audio-out setting while you're there.

Restart MPD: first kill it by PID number found by 'ps' then start by mpd (no sysctl or systemd in default busybox) . Now mpc will have hopefully controle and some information on mpd.

Now on to even more remarkable easy to forget nooks and crannies:

We do want that i2s-dac thing running. In the picture is a simple (i2s-slave) interface that doesn't need any configuration (by i2c). I think most of these simple boards will work, this one is an old hifiberry-dac with a pcm5102a. That is a significant hint to get it going:

First comment out the 'dtparams=audio=on' and add in 'dtoverlay=hifiberry-dac' in the aforementioned config.txt file.

But you will not have any overlays in that 'boot' directory. So download it from some github or strip it from some other distro. Probably kernel versions and .dtbo file will have some relation...

Now for the similar modprobing:

You need the 4 of them to get it going:

snd-soc-bcm2835-i2s, snd-soc-core, snd-soc-pcm5102a, snd-soc-rpi-simple-soundcard.

Finally! Audio from your i2s board!

Now to make it persistent after reboot, you have to make a little script in the '/etc/init.d' . Give it number some lower as the mpd-start-stop script, which in my case was S95. (that's capital S!)

Don't forget to mount your USB-music-drive before starting mpd. I edited the mpd start script to mount the drive: the usual fstab methode doesn't work to well. Presumably the default mpd start script will be started before the USB drive is ready for mount.

Other nice stuff to implement:

We can us sysfs-kernel modules to manipulate GPIO ports. Make sure the pins are not in use for other functions (like i2s..duh). Here is a small script:

#!/bin/sh

#gpio17 to drive a led:
echo 17 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio17/direction

#gpio27 to have a push button to do "mpc next":
echo 27 > /sys/class/gpio/export
echo in > /sys/class/gpio/gpio27/direction

while true
do
if mpc status | grep -q 'playing'; then
  echo 1 > /sys/class/gpio/gpio17/value
else
  echo 0 > /sys/class/gpio/gpio17/value
fi

if cat /sys/class/gpio/gpio27/value | grep -q '1'; then
  mpc next
fi

sleep 0.5

done

Oh, and one more thing:

Before starting to use something like 'buildroot' think of a way to separate everything from your everyday-work-computer. It will give a big mess if you don't. I used VMware. Do configure for plenty of drive space!

TAC Scorpion revival

Back in the days when everybody was using some Soundcraft n*200 (n = 1,2,3,4..) mixingdesk I used to prefer a TAC scorpion console. We are talking end '80 begin '90 here..

So this is my, way to much work, project to investigate why I did prefer that console over others and at the same time make it a bit more 2022.

Now this is most certainly not how these consoles looked, so lets start with a picture of a original TAC Scorpion:

This is not my original console, that one has disappeared into oblivion. But very similar to the one shown on the left, all VU meters where broken. They all had that after a year or 2..

So instead of trying to fix those first thing I did was get rid of some heavy metal casing. Boy are these things made like heavy armoured tanks.

I do like VU meters on every channel though! Not as much to adjust gaining (o, man I can rant on about that one). But they really come handy to quickly see which synth/sequencer/voc channel is doing that solo in a live situation😏

So I made a VU board with a vintage chip everybody knows: LM3915. As there is no audio passing through this chip I didn't care where it came from: Aliexpress FTW! I did design a simple pcb in cool black and here you go diy VU meter:
I mounted them to the faders which I had to clean anyway. And I used the same feed point for fader and the measuring entry (as in PFL), so no long lines running across the console..

..to be continued

STM32 in final 'product'

Let me write a round up of this research on using a MCU as a speaker processor.

By this time I switched from KEILmdk to STM32CubeIDE which at this moment (november, 2021) seems to be the weapon of choice for most STM developers.

Again for future reference a quick how to on how to include a math / DSP library.

Together with your installation of the IDE you also will have installed some repositories for ARM software products. You are looking for CMSIS/DSP libraries. The path will be something like /STM32Cube/Repository/STM32Cube_FW_F4_V1.25.2/Drivers/CMSIS/DSP/ in your home directory (in Linux). It will be similar in MacOS or Windooz.

Start a new project in the IDE, right click on projects name and Create new source folder. Name this folder DSP. Now again right click and select Import file system. Select both the source (source) and the header (include) file as in the screenshot from the above mentioned 'repository'. Click finish.

Now you will have both the source and header files in your project but your compiler knows nothing about it so: right click project and find the project properties setup. Find the compilers include path settings and add the new path to your include file. Check the screenshot.

Now you can include all these nice ARM DSP tricks by:#include "arm_math.h" Try to build (that's embedded speak for compile)... Hundreds of errors, but if you check the firsts you will see that the compiler needs two PreProcessor directives. Find those in properties and add both: ARM_MATH_CM4 (we are using a M4 core) and __FPU_PRESENT = 1U (yes, we do have a floating point dohickey in our processor). O, and that's two/2 underscores! __

Now you can start programming your code making use of block processing, taking chunks of say 48 samples using the increased efficiency of the CMSIS libraries.

Check all those filtering functions!!

There's loads to discover but let me disclose this one:

Decades ago I met Ed Long (yup, the guy who 'invented' Time-alignment) at a proaudio trades fair. He demonstrated his closed box, single 15' sub. That was astounding (as was the excursion). His trick was to use electronics branded as ELF and not filters to EQ the sub.

Much later Linkwitz developed a filtering method known as Linkwitz Transform. A similar way to correct the response of a sub woofer.

Never got any good results with this method as in professional DSP's don't provide for a method to import your own Biquad coefficients. And using shelving filters and EQ will never have the required precision.

While using this CMSIS library function:

void	arm_biquad_cas_df1_32x64_q31 (const arm_biquad_cas_df1_32x64_ins_q31 S, const q31_t pSrc, q31_t *pDst, uint32_t blockSize)
	Processing function for the Q31 Biquad cascade 32x64 filter.

I managed to reproduce that sensation I had at that trade fair decades ago..Thanks Ed!

Do understand that you really, really need the above precision (in fixed point) to get any decent results! If you are into the math: understand how a biquad calculation works and how the representation of coefficients (which are all close to the unity circle) will effect the calculations at very low frequencies.

(anyone remember we at some point (2010?) got this 'use for better LF response' check box in LondonArchitect? )

Posted on Instagram you can find some pictures of cabinets where I did apply this.

----->

Oh, and this is the latest board I developed, everything being stalled a bit by the global chip shortage:

pages

Fighting long boot times when using older RPI

TAC Scorpion revival

STM32 in final 'product'