Digital multi-FX pedalboard

[Firesledge]

Hi,

I'm currently building a digital multi-FX pedalboard. It is based on a Raspberry Pi 3 and a USB audio interface.
Well, the hardware is now ready and the software is still in development, but already usable with nice effects and control possibilities.

There is a page here describing the project, albeit the building instructions and user manual are not translated in English yet (French, sorry, but there are a few pictures).
There is also an "emulator" program for Windows, which helps me to develop and test the software side.

I'm progressively adding new effects and improving the user interface. I also consider dropping the USB audio and building my own ADC/DAC board, but I'm a bit afraid of soldering TSSOP chips. I guess I'll need practice...

[key-bored]

What an AMAZING project.  I'm very impressed.
Hope to see it in English.
I tried to do a Google translate, but the translator gives up shortly into the page, so I can't read most of it.
Hope to see it going.
Personally, I'll be interested in the 0dB version because I'd use it with keyboards and such.


KB

[Firesledge]

You can just set the input gain on the audio interface to match the level of your keyboard.

[ElectricDruid]

Very cool! I look forward to seeing this develop.

Good luck with the software!

Tom

[Firesledge]

I just did a presentation video for my Pédale Vite pedalboard (French with English subtitles)

[Firesledge]

I also consider dropping the USB audio and building my own ADC/DAC board

I build an audio card based on the Cirrus Logic CS4272, with instrument inputs, mic preamps and balanced outputs. The hardware is working as expected, but I struggle to implement a driver. My board communicates with I2S for audio, and I2C for commands (optional, I can use the standalone mode of the CS4272). I also have two additionnal GPIO pins, one for reset, the other one to select the base sampling rate (44.1 or 48 kHz). The chip works in master mode, generating the bit and word clocks from and external MCLK provided by a PLL. Therefore the Pi 3 works in slave mode.

The 4272 is compatible with the 4272 which already has an implementation in ASoC. By copy-pasting and mixing Device Tree code from other Alsa SoC drivers, I succeeded to get something usable (based on the simple-card), but with hardcoded 44.1 kHz sampling rate. That's where I would need help: I don't know how to setup things to tell the system which sampling rates are available and how to switch between the base rates by setting the GPIO pin state. I quite new to Device Tree and linux drivers so wonder where to get proper documentation about ASoC drivers, the properties of the different layers and how to glue everything. Here is my device tree overlay so far:

Code Select Expand

/dts-v1/;
/plugin/;

/ {
compatible = "brcm,bcm2708";

fragment@0 {
target = <&sound>;
__overlay__ {
compatible = "simple-audio-card";
i2s-controller = <&i2s>;
status = "okay";

simple-audio-card,name = "PVAudioBoard";

simple-audio-card,widgets =
"Line", "Line In",
"Line", "Line Out";

simple-audio-card,routing =
"Line Out","AOUTA+",
"Line Out","AOUTA-",
"Line Out","AOUTB+",
"Line Out","AOUTB-",
"AINA","Line In",
"AINB","Line In";

simple-audio-card,format = "i2s";

simple-audio-card,bitclock-master = <&dailink0_slave>;
simple-audio-card,frame-master = <&dailink0_slave>;

simple-audio-card,cpu {
sound-dai = <&i2s>;
dai-tdm-slot-num = <2>;
dai-tdm-slot-width = <32>;
};

dailink0_slave: simple-audio-card,codec {
sound-dai = <&cs4271>;
system-clock-frequency = <11289600>;
};
};
};

fragment@1 {
target = <&i2s>;
__overlay__ {
status = "okay";
};
};
   
fragment@2 {
target = <&i2c1>;
__overlay__ {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";

cs4271: cs4271@10 {
#sound-dai-cells = <0>;
compatible = "cirrus,cs4271";
reg = <0x10>;
reset-gpio = <&gpio 5 0>;
vd-supply = <&vdd_3v3_reg>;
vl-supply = <&vdd_3v3_reg>;
va-supply = <&vdd_5v0_reg>;
status = "okay";
};
};
};
__overrides__ {
gpiopin = <&cs4271>,"reset-gpio:5";
};
};


Any help would be very welcome. Thanks

[gmaslin]

Have you had a peek into this thread? My concept applied to your unit might lead to great miniaturization and efficiency by reducing the number of pots and switches. By separating the two modulation controls (pitch and volume), I believe a motorized pot or smaller switch set can be used to change only the nature of the modulation as described in the thread. Example below:

one 3P switch to change the wave from square to saw or sine.
one pot to skew the wave on the horizontal axis while keeping the same frequency
two pots to change the frequency rate and pitch
one pot to skew the wave on the vertical axis without changing amplitude
one dedicated  and separate gain control
One pot or switch as a blend, channel adding control

Your thoughts?

[Hamuro]

Wow that's great, how about the latency? Does it work non-block processing with only 1/(sampling rate) latency?
It always tempting for me to build such a polyphonic guitar synthesizer that worth $1k at the current market 

[Firesledge]

Have you had a peek into this thread?

This could be done, of course. The effect itself looks not too complicated. However it is probably not the best solution if you want to build a single stompbox implementing the effect you describe. There are much simpler platforms.

Wow that's great, how about the latency? Does it work non-block processing with only 1/(sampling rate) latency?

On the current working setup using a USB audio interface, measured latency is 13.4 ms, processed in blocks of 64 samples. It is not possible to do sample per sample processing. And even if it was, the actual latency would be bigger because of the ADC/DAC antialiasing filters. Anyway with my new interface, I hope getting better performances, at least by removing the USB from the loop.

[Blackaddr]

Yup, you need an FPGA to get sample-by-sample processing.

[Firesledge]

Finally I gave up on the ALSA driver. Even with my device tree overlay, the performances were hardly on par with the USB audio board.

So I wrote custom code to directly drive the BCM's PCM/I2S interface from my program. The results are much better. With 64-sample buffers, I get something close to 3.5 ms of latency for a round trip, which is much better than the previous 13.4 ms with the USB audio board. 16-sample buffers give me 1.7 ms and the processing looks still stable, but CPU load is higher. The constant part of the latency is about 30–40 samples, 24 of them are from the antialiasing filters (and could be halved by selecting the fast roll-off filters on the codec). I guess that others come from the RX/TX FIFOs in the I2S interface and serial data transmission. So going lower in the buffer size is probably not worth it, given the current HW architecture.

Anyway 3.5 ms is perfectly fine for me, so I can now work on integrating the audioboard into the pedalboard (or make a new one with other improvements).

[Firesledge]

So I built a fully working v2 of my Pédale Vite. Much thinner, upgraded to RPi4 and better audio interface and display. Check here for building instructions, user manual, pictures and audio examples.

[pruttelherrie]

Question: shouldn't 16-sample buffers give you half of 1.7ms latency, being a quarter of the 3.5ms latency of a 64 sample buffer?

[Firesledge]

These are the figures I measured with a scope. You always have a constant latency caused by the ADC + DAC anti-aliasing filters, communications and other internal processing on the audio interface side. Then on the CPU side, the latency associated with the processing buffers, which is roughly proportional to the buffer size.