[sdiy] In praise of the ATM STM32F303

[Olivier Gillet]

I've benchmarked a few methods for sawtooth generation on a STM32F4 at
168 MHz, 48kHz sample rate.

I went for floats - in the past I've tried several times rewriting the
code of some of my modules for fixed point and never obtained
improvements...

We're talking about 128 sawtooth oscillators, from MIDI note 0 (8.17
Hz) to MIDI note 127 (12.5 kHz). Buffer size is 48 samples. I measured
the % CPU used by the rendering routine.

Table lookup with linear interpolation: 98%, with only 118 oscillators
running. This rules out Tomisawa's method which would need a sine
table lookup.
Naive sawtooth: 51%
Polyblep: 90%
Polyblep with manually unrolled loop: 73%
Optimized polyblep: 45%.

The optimization works as follow: we can assume that the period is
constant and equal to N samples. The first [N-4] samples are computed
naively, without using any check for phase overflow. The remaining
samples are computed using polyblep code to get the smooth transition
at the right place. The most common case is thus long unrolled
sequences of the following instructions: vldmia, vfma.f32, vadd.f32,
vstr

That's an average of 12.3 CPU cycles per oscillator per sample, so
this could still run on the 72 MHz F3 at a slightly lower sample rate.

Code:
https://gist.github.com/pichenettes/bace97ca523a434a1ee6

On Fri, Feb 12, 2016 at 3:52 PM, Olivier Gillet <ol.gillet at gmail.com> wrote:
>> I didn’t know this, it sounds interesting! Does it mean that you could get away with not band-limiting your oscillator’s waveforms, and always "snap" their frequency to a multiple/divider of the DAC clock? And generate the DAC clock from one of the high-res timers on the STM?
>
> If you're only interested in pure digital generation, you don't even
> have to use this feature - you can also directly alter the frequency
> of the timer that clocks the DAC updates. This works well for simple
> monophonic waveform generation. I considered using it for a while for
> Braids, before realizing that half of the algorithms I wanted to
> implement required two oscillators, or that the variable frequency
> complicated the calculations (for example for the models in which
> there are filters).
>
> This variable-rate clocking approach is not very suitable for
> polyphony - if you want to play two distinct frequencies, you'll need
> two timers and two DACs...
>
> Colin's suggestion is about using an external clock source, such as a
> VCO, to clock the reads.