Chris Anderson @chrisanderson1973@librem.one

It's been a while, but I simply had no "spark" as far as writing new/interesting software is concerned, for the last little while.

This is related to a work project, but I am well on my to creating a Qt/Golang-based Modbus simulation program. I have managed to bind Qt/Quick/Qml to Go, and this is all enough to run a full-blown simulation. More to come.

I am switching directions, but I am getting into what all I'd really like to do anyway, and that's solve a problem I have always seen with audio production setups. So, the new goal is to mostly skip over reinventing the wheel (USB audio) and delve into digital audio workstation development using embedded Linux and various control. Lots more to come.

This kind of took most of Sunday, but whatever.... I built Audacity for the Yocto embedded Linux. I have a graphical environment already, so it will be handy to have access to Audacity to get a summary of the audio capabilities on the Apalis iMX8 platform. Plus a little fun running Spotify in Fedora.

Audacity - I am building this on the iMX8 system to test out the basic audio interfaces that are provided between the iMX8 Apalis SOM and Ixora carrier board.

Living the dream! I have some hardware work to do on the STM32 (ie. making a whole design on a printed circuit board) before I can do much more with that system. A limiting factor, as well, is the latency minimization on the USB audio interface. It's still manageable to use for a certain number of effects, but I need to make sure that I can do enough audio processing to have a viable product. The backup is Linux, and I will pursue that in the coming weeks, as well.

In working with the current platform tonight, I found that the USB audio interface is a limiting factor for signal processing - on the same processor. The buffer size is set at 48 bytes, due to the sample rate of USB FS and the audio sample rate. This is great for the USB audio interface, as the fairly latency is low, but between this and the short cycles between ADC transfers, effects processing is not ideal. So, the way forward now is...back to Linux, mostly.

Well, this is how development should/can run - start over early enough to not get into a bind. So, I have decided to take a sledge hammer to my current "issues" in using the STM32F407VG as the basis for a "simple" audio effects USB device. With this, I am seeing why these devices run up in cost. Getting to the crux of my issue(s): I can either upgrade the STM32 and still sacrifice a few features...or jump to an old reliable...the IMX6 running Linux!

Distortion! Learning a bit more about creating distortion with simple DSP routines. I have been wrestling with an issue where too few samples (as in none) were being skipped to compute whatever it takes to provide sine/cosine/modulo, etc. Other DSP algorithms I had used in AnaddrSynth - running on the iPad - even had some skips. So, this was a great lesson!

I finished the serial port management, as far as reconnection is concerned. This makes debugging and restarting the audio device much simpler. I also verified the distortion effects' gain setting and adding the module to the effects chain. Good session.

Getting into packets agains this afternoon, finding a way to embedded module type, command type, command end/begin, etc. At the moment, I am getting a gain value across, encoded as uint32, which takes some work. I will have to work on the decode on the STM32 side, as well.

So, I got into making up a very, very simple module - a saturation module - requiring one parameter. However, the thought occurred to me that I really need a packetization system in order to differentiate between modules and which ones need what settings, etc. So, this afternoon has been dedicated to that - which is still fun! I love it when I can take IEEE standards and use those to get things done.

A nice stint today as I made the initial audio chain and update to the effects box work. There is no audio, yet, but I could probably try some of that soon. The QT app can now create an audio effects pipeline, basically, in the effects box. The plus side is that the Mac can be used to create and control the audio effects pipeline. The downside is that only the Mac and a connection to effects box lets everything work. More work to do!

I had to work with the data structures and serial interface a little more, and mainly to ensure that the QT framework's primary serial library would work ok. Everything looks good and I think I can start planning / implementing the settings data structures.

As it turns out, the Qt app did not have a bad start on organizing the modules. There are two lists to go by, and it takes a cross reference to obtain both the order of modules and module type. I'll have to optimize this a bit soon; but, for now, I have a workable solution to returning the correct device manifest for the effects box.

A bit of work today to integrate the QT application with the USB audio device. I also worked on module process / type setting, and adding. I can now add a reverb module on the QT application graph and have the effect added to the USB audio device's "effects array". More to come....👍

It's nice to be creating stuff again! The day job is fine, but there is not much room to reinvent the "framework" at the moment. So, here I am in C, inventing a way to pass along settings from the Qt app to this effects box.

Ha - well, that went well! It looks like alien wah works very reasonably within the STM32 realm! A couple of videos here!

This is a big test of the platform, I guess. I am attempting to port an effect from the iPad/iOS synth I released in 2014 and 2019. It's called "alien wah" and it was a hit with users on the App Store. I have around 512Kbytes of memory to work with, so I think the effect can fit in an effects chain. I may have to limit the number of instances - but it may only make sense to use it once in a chain, anyway. This gets tricky if the platform goes stereo, and a memory expansion is needed..

First bit of DSP in effect! This is a simple notch filter to get things going. It works well, except that I need to get rid of any blips between switching filters/effects on and off.

Yeah, now I have the serial ack/nack verified and working. The initial setup doesn’t quite work the way it should, but I can look into that part later. I did manage to test the audio working alongside transmit/receive, and it seems pretty decent.