[PD-announce] [ot] new hardware synth // technical thought about real time in embedded system

cyrille henry ch at chnry.net
Wed Apr 13 19:18:11 CEST 2016


hello,
this is a bit OT since pd is not involve in the final project, but I use pd a lot to design all algorithm.
and i wanted to share with you my latest production.
so, here it is :

http://chnry.net/ocs/

A digital, semi-modular, analogue style, hardware synthesizer.
(go to the website if you want commercial arguments about this synth)


The band-limited oscillator algorithm came from the saw~ object in nusmuk audio.
(the other are mostly variation around saw~ + some i still have to clean and commit)
the filter is the one I send recently on the pd-list. It is also in nusmuk-audio.
the rest is easy to implement in pd.
So everything can be done in a patch, but having a hardware fader with 12 bit precision give better control than a mouse on a 7 bit precision slider.


This project was also a way to test platform for real time embedded system. As a pd user, it was natural to make a patch and use it on a raspberry pd. But this was not satisfying as an embedded platform in many aspect (limited cpu processing power, latency, boot time, ...).
Fixing all of this aspect would require a huge amount of work and competences. (going bare metal by example).

but i took an other direction : in order to increase performances, i downgrade the hardware!

I use an arduino due. It has a 32bit core at 82Mhz. It is 10 time slower than a raspberry pi, but not having any operating system solve lot's of problems.
About boot time : well, no need to optimise anything on an arduino to have boot time < 1ms.
about latency : the micro-controller allow interruptions. it's a kind of multi-threading : the main thread is stop at every sample receive from the audio ADC, start the interrupt thread, and go back to the background thread as soon as the interrupt thread is finish.
This allow per sample accuracy : there is no buffer in the arduino. The latency came only from the 3 or 4 samples buffer in the audio dac (used for oversampling).
about performance : this is the best surprise. The cortex M3 micro-controller did not compute float, but it is very powerful with int. I have to rewrite everything from scratch using only 32 bit int.

At first i try to stay as close a asm as possible in order to control every instruction cycle. I fail, but I realize that gcc is great at optimising stuff and give him more space. Of course, the only mathematical instruction to use is addition, subtraction, 32 bit multiplication, 32 bit division and eventually 32x32->64 bit multiplication. everything else is prohibited. (>> and << is encouraged since it can be done prior to a mathematical instruction on the same clock tick).

Having the hardware to deal with peripherals is also something that save CPU (no need for usb communication to get fader value, the 12bit adc is included in the arduino chip). And not having any buffer also same CPU.

so, an optimized code can run faster on an arduino due than a not opimized patch on a raspberry pi.

Anyhow, the work was a bit like trying to fit an elephant in a shoes box. But I spend less time to rewrite the patch than to optimized a raspberry pi.

So, the main idea is that if you want to be real time, stop trying to optimize your OS. remove your OS. it's not harder.

cheers
c



More information about the Pd-announce mailing list