ESP32-A1S audio dev board

[Digital Larry]

i think using the LPU processor is a thing reserved for geniuses only.. but i know you are one

Yeah sure, of course I am.  What's an LPU?   

Here's what I really am.  I studied DSP at university (that's the British way of saying "in college") many many (many) years ago.  I thought it was amazing but it was all theoretical and simulation.  We didn't have anything to run our guitars through.  Then I had an engineering career that didn't get into that too much (although it did just a little).  Now I'm on the far side of my career and things have progressed to the point where I can mess with all this stuff using easily available relatively cheap development platforms.  So I'm making up for lost time.

I can't read anything and get much out of it without getting my hands on... and that's what you see in this thread.  I am persistent and stubborn and like learning new things but also making stuff go wee weee weeee peyoowwww bing doot doot while I'm at it.

DL

[dschwartz]

i think using the LPU processor is a thing reserved for geniuses only.. but i know you are one

Yeah sure, of course I am.  What's an LPU?   

Here's what I really am.  I studied DSP at university (that's the British way of saying "in college") many many (many) years ago.  I thought it was amazing but it was all theoretical and simulation.  We didn't have anything to run our guitars through.  Then I had an engineering career that didn't get into that too much (although it did just a little).  Now I'm on the far side of my career and things have progressed to the point where I can mess with all this stuff using easily available relatively cheap development platforms.  So I'm making up for lost time.

I can't read anything and get much out of it without getting my hands on... and that's what you see in this thread.  I am persistent and stubborn and like learning new things but also making stuff go wee weee weeee peyoowwww bing doot doot while I'm at it.

DL

sounds like a genius to me....curious, stubborn and hands on..

i think the second processor is sometimes referred as LPU (low power unit)  or it was ULP?? idk...

[Digital Larry]

I got some primordial OSC code from a student on the Faust Slack channel and am going to try incorporating this into my flanger/echo patch today.  I was able to get messages from TouchOSC over my WiFi LAN down to the ESP32 board.  Now I just need to hook them up to control sound parameters.  Well, I was looking for an excuse not to leave the house anyway right?  On a little Android 8" tablet that nobody was using any more I can get around 20 rotary controls and a few push buttons.  This is way easier than dealing with I2C and (gasp) "soldering" (shudders).   

While this is not the same as native OSC support in Faust, such as you have on a Bela or other more mainstream Faust targets, it's also more flexible as it passes through your own C++ code so you're not limited to having it only affect the sound algorithm.  At this point I don't know what else I'd be wanting it for, although something like saving presets might be possible.

DL

[Digital Larry]

OK, I got buttons working, I got OSC working.  I've been using the ef.echo() function from Faust libraries but unfortunately, the output comes after the feedback control, which means that as the feedback goes down, so does your overall echo level.  I'd rather have an independent control of echo level and feedback.  So I have to build my own block out of something else.

I am trying the de.sdelay() which lets you change delay time without glitches or pitch bending.  I think it does this by using two different delay lines and fading between them when you change the delay time.  Some of its behavior is a little weird though, for example:

a) Delay = 50%, echoes are at 50%
b) Change delay to 75%, sound echoing from before is still repeating at 50%
c) Newly added sounds repeat at 75% (I think)
d) Change delay to 25%, now sounds from (a) and (c) are repeating at 25% (being chopped off)

That's what I THINK is happening anyway.  There are a number of different delay types to choose from, or if I get suitably desperate I could try to assemble my own from low levels.  I actually don't mind delays which pitch shift, but I think I'd need to slow down the control signal a bit more since at present it's a bit jumpy (just using si.smoo() - if you use si.smooth() then you can adjust the rise time explicitly).

Next up, initially I was configuring the OSC controls in touchOSC to send a message like "/flanger/flgDelay" and then, in the udp server block which handles OSC, look for that and then send a parameter adjustment message to the Faust code, using "flangeDelay".  However I realize it would make more sense to just look for "/flanger/" in the messages, trim off the end if there is a match, and send the rest to the Faust block rather than doing an intermediate lookup to change the variable name.

DL

[dschwartz]

Are you accessing the external ram for the delays?

[Digital Larry]

Are you accessing the external ram for the delays?

Yes, I can get about 2.5 seconds of delay.

[Ben N]

I can't read anything ...

Ah, a guitar player. 

[Digital Larry]

Once again I'm exploring the edges of what will run on this chip.

At the moment I have a nice flanger with adjustments on:
- initial delay time
- lfo rate
- lfo width
- depth (wet mix)
- feedback

This is fed by a delay line with adjustments on:
- delay time
- feedback level

As Faust's built-in "ef.echo()" function does not have a level control, only delay time and feedback controls, I had to build my own out of de.sdelay() and the dreaded "recursion" operator.  I finally figured out how to put the delay into the feedback loop.  Then I went to add a 4 pole low pass filter and started getting watchdog timer errors.  This means "you're trying to execute too much code".  I whittled that down to a 2 pole filter and it worked again.  Then I went to add a level control and it stopped working.

There are some benchmarking tools for Faust generated code but I'll be danged if I have any clue as to how to use them.

Since I've done a lot of work with the Spin FV-1 I'll just note some apparent advantages of each platform, please note, "it's just my opinion, man..."

Advantages of Spin FV-1
- seems like it can do more processing before running out of CPU cycles, e.g. reverbs, complex modulations, multiple filters
- easier to incorporate into your own designs due to SOIC package and integrated A/D/A circuitry.
- probably a shorter learning curve, hard to be objective about it though.  Everything you learn about the FV-1 has to do with the FV-1's audio algorithms, while some things you have to learn about the ESP32 have to do with setting up the development environment, learning how freeRTOS works, etc.
- has awesome graphical tool SpinCAD Designer to help you come up with algorithms
- highly optimized instruction set for DSP
- very obvious when you've run out of code execution space - it won't assemble
- better S/N (at least compared to the AI Thinker board)
- can store programs in a cheap EEPROM and switch between them easily.

Advantages of ESP32-A1S board
- up to 2.5 seconds of delay time if you enable malloc() to work with SPIRAM
- can connect to your LAN via Wi-Fi so you can use OSC to go past 3-control limitation of FV-1
- cheaper than FV-1
- works with awesome but possibly incomprehensible "Faust" language for developing portable algorithms
- more flexible control I/O arrangement... but you either have to find analog input pins to connect pots or use I2C to get those in and pass parameter changes to the DSP code.

===============
I also have the LyraT board which supposedly has better S/N as the codec chip is not on the ESP32 module and they seem to have done a better job of providing it with an isolated power supply, etc.

I think that the ESP32 based boards are likely suitable for single-effect types of applications with a lot of controls.  I was quite often frustrated by the 3-pot limitation on the FV-1 as I could easily come up with complex algorithms that could have used more.  Even if ultimately I decide that I don't need all these controls, or might combine 2 into 1, it's really hard to know unless you have more flexibility at the initial stages.

DL

[hgamal]

Hi Larry,

All right, here's my code for a basic mono flanger which uses the 6 pushbuttons of the AI-Thinker ESP32-A1s audio/wifi/bluetooth dev board to adjust LFO width, speed, and flanger center delay.
...

I've tried to run your code and I've got: "***ERROR*** A stack overflow in task Faust DSP Task has been detected."

Any suggestion?

complete log follows:

Code Select Expand


I (75) boot: Chip Revision: 1
I (75) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (43) boot: ESP-IDF v3.3.1 2nd stage bootloader
I (43) boot: compile time 21:54:41
I (52) boot: Enabling RNG early entropy source...
I (52) boot: SPI Speed      : 40MHz
I (52) boot: SPI Mode       : DIO
I (55) boot: SPI Flash Size : 4MB
I (60) boot: Partition Table:
I (63) boot: ## Label            Usage          Type ST Offset   Length
I (70) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (78) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (85) boot:  2 factory          factory app      00 00 00010000 00100000
I (93) boot: End of partition table
I (97) boot_comm: chip revision: 1, min. application chip revision: 0
I (104) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x156a8 ( 87720) map
I (144) esp_image: segment 1: paddr=0x000256d0 vaddr=0x3ffb0000 size=0x01f78 (  8056) load
I (147) esp_image: segment 2: paddr=0x00027650 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /home/hgamal/esp/esp-idf/components/freertos/xtensa_vectors.S:1779

I (151) esp_image: segment 3: paddr=0x00027a58 vaddr=0x40080400 size=0x085b8 ( 34232) load
I (174) esp_image: segment 4: paddr=0x00030018 vaddr=0x400d0018 size=0x23138 (143672) map
0x400d0018: _flash_cache_start at ??:?

I (225) esp_image: segment 5: paddr=0x00053158 vaddr=0x400889b8 size=0x060e8 ( 24808) load
0x400889b8: rtc_init at /home/hgamal/esp/esp-idf/components/soc/esp32/rtc_init.c:78

I (244) boot: Loaded app from partition at offset 0x10000
I (244) boot: Disabling RNG early entropy source...
I (244) psram: This chip is ESP32-D0WD
I (250) spiram: Found 64MBit SPI RAM device
I (253) spiram: SPI RAM mode: flash 40m sram 40m
I (259) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (266) cpu_start: Pro cpu up.
I (270) cpu_start: Application information:
I (274) cpu_start: Project name:     hello-world
I (280) cpu_start: App version:      1
I (284) cpu_start: Compile time:     Apr 21 2020 21:54:44
I (290) cpu_start: ELF file SHA256:  23fecd3f8d509e36...
I (296) cpu_start: ESP-IDF:          v3.3.1
I (301) cpu_start: Starting app cpu, entry point is 0x40081264
0x40081264: call_start_cpu1 at /home/hgamal/esp/esp-idf/components/esp32/cpu_start.c:269

I (0) cpu_start: App cpu up.
I (1192) spiram: SPI SRAM memory test OK
I (1192) heap_init: Initializing. RAM available for dynamic allocation:
I (1193) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1199) heap_init: At 3FFB3070 len 0002CF90 (179 KiB): DRAM
I (1205) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1211) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1218) heap_init: At 4008EAA0 len 00011560 (69 KiB): IRAM
I (1224) cpu_start: Pro cpu start user code
I (1229) spiram: Adding pool of 4096K of external SPI memory to heap allocator
I (244) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (245) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (1255) AC101: reset succeed
I (1375) AC101: init done
I (1375) gpio: GPIO[21]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (1375) BUTTON: configuring GPIOs
I (1375) gpio: GPIO[5]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:1073433824
E (1385) gpio: gpio_set_intr_type(102): GPIO interrupt type error
I (1395) gpio: GPIO[13]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:1073433824
E (1405) gpio: gpio_set_intr_type(102): GPIO interrupt type error
I (1415) gpio: GPIO[18]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:1073433824
E (1425) gpio: gpio_set_intr_type(102): GPIO interrupt type error
I (1425) gpio: GPIO[19]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:1073433824
E (1435) gpio: gpio_set_intr_type(102): GPIO interrupt type error
I (1445) gpio: GPIO[23]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:1073433824
E (1455) gpio: gpio_set_intr_type(102): GPIO interrupt type error
I (1465) gpio: GPIO[36]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:1073433824
E (1475) gpio: gpio_set_intr_type(102): GPIO interrupt type error
I (1475) BUTTON: Pin count: 6
I (1485) BUTTON: Registering button input: 5
I (1485) BUTTON: Registering button input: 13
I (1495) BUTTON: Registering button input: 18
I (1495) BUTTON: Registering button input: 19
I (1505) BUTTON: Registering button input: 23
I (1505) BUTTON: Registering button input: 36
I (1515) I2S: DMA Malloc info, datalen=blocksize=1024, dma_buf_count=3
I (1515) I2S: DMA Malloc info, datalen=blocksize=1024, dma_buf_count=3
I (1525) I2S: PLL_D2: Req RATE: 32000, real rate: 32894.000, BITS: 32, CLKM: 19, BCK: 4, MCLK: 8192000.000, SCLK: 2105216.000000, diva: 64, divb: 34
***ERROR*** A stack overflow in task Faust DSP Task has been detected.
abort() was called at PC 0x400880f4 on core 1
0x400880f4: vApplicationStackOverflowHook at /home/hgamal/esp/esp-idf/components/esp32/panic.c:715


[Digital Larry]

Hi Haroldo,

Here is my boot trace, let's see if there are some obvious differences.

a) I'm using ESP-IDF 4.0, you've got 3.3-something
b) you're calling rtc_init, I may have disabled rtc in my sdkconfig.
c) you seem to be getting GPIO interrupt type errors - don't know why
d) (make menuconfig): Component config → ESP32-specific : I have set CPU clock to 240 MHz, which was not the default

That's all I can see at the moment, please check as there may be something else.

Code Select Expand


I (69) boot: Chip Revision: 1
I (70) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (39) boot: ESP-IDF v4.0-dirty 2nd stage bootloader
I (39) boot: compile time 01:21:45
I (47) boot: Enabling RNG early entropy source...
I (48) boot: SPI Speed      : 40MHz
I (48) boot: SPI Mode       : DIO
I (52) boot: SPI Flash Size : 4MB
I (56) boot: Partition Table:
I (59) boot: ## Label            Usage          Type ST Offset   Length
I (67) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (74) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (81) boot:  2 factory          factory app      00 00 00010000 00100000
I (89) boot: End of partition table
I (93) boot_comm: chip revision: 1, min. application chip revision: 0
I (100) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x0d908 ( 55560) map
I (132) esp_image: segment 1: paddr=0x0001d930 vaddr=0x3ffb0000 size=0x02040 (  8256) load
I (136) esp_image: segment 2: paddr=0x0001f978 vaddr=0x40080000 size=0x00400 (  1024) load
0x40080000: _WindowOverflow4 at /home/gary/ESP32-A1S/esp-idf/components/freertos/xtensa_vectors.S:1778

I (139) esp_image: segment 3: paddr=0x0001fd80 vaddr=0x40080400 size=0x00290 (   656) load
I (148) esp_image: segment 4: paddr=0x00020018 vaddr=0x400d0018 size=0x1fbe0 (130016) map
0x400d0018: _stext at ??:?

I (210) esp_image: segment 5: paddr=0x0003fc00 vaddr=0x40080690 size=0x0d570 ( 54640) load
I (244) boot: Loaded app from partition at offset 0x10000
I (244) boot: Disabling RNG early entropy source...
I (245) psram: This chip is ESP32-D0WD
I (249) spiram: Found 64MBit SPI RAM device
I (254) spiram: SPI RAM mode: flash 40m sram 40m
I (259) spiram: PSRAM initialized, cache is in low/high (2-core) mode.
I (266) cpu_start: Pro cpu up.
I (270) cpu_start: Application information:
I (275) cpu_start: Project name:     basicFlanger
I (280) cpu_start: App version:      v4.0-dirty
I (285) cpu_start: Compile time:     Apr 22 2020 01:21:57
I (292) cpu_start: ELF file SHA256:  b74d35872ec7cb77...
I (298) cpu_start: ESP-IDF:          v4.0-dirty
I (303) cpu_start: Starting app cpu, entry point is 0x40081374
0x40081374: call_start_cpu1 at /home/gary/ESP32-A1S/esp-idf/components/esp32/cpu_start.c:272

I (0) cpu_start: App cpu up.
I (1190) spiram: SPI SRAM memory test OK
I (1191) heap_init: Initializing. RAM available for dynamic allocation:
I (1191) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (1197) heap_init: At 3FFB5050 len 0002AFB0 (171 KiB): DRAM
I (1204) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (1210) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (1217) heap_init: At 4008DC00 len 00012400 (73 KiB): IRAM
I (1223) cpu_start: Pro cpu start user code
I (1228) spiram: Adding pool of 4096K of external SPI memory to heap allocator
I (1249) spi_flash: detected chip: generic
I (1249) spi_flash: flash io: dio
I (1259) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
I (1259) spiram: Reserving pool of 32K of internal memory for DMA/internal allocations
I (2269) AC101: reset succeed
I (2389) AC101: init done
I (2389) gpio: GPIO[21]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (2389) BUTTON: configuring GPIOs
I (2389) gpio: GPIO[5]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:5
I (2399) gpio: GPIO[13]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:5
I (2409) gpio: GPIO[18]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:5
I (2419) gpio: GPIO[19]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:5
I (2429) gpio: GPIO[23]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:5
I (2439) gpio: GPIO[36]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:5
I (2449) BUTTON: Pin count: 6
I (2449) BUTTON: Registering button input: 5
I (2459) BUTTON: Registering button input: 13
I (2459) BUTTON: Registering button input: 18
I (2469) BUTTON: Registering button input: 19
I (2469) BUTTON: Registering button input: 23
I (2479) BUTTON: Registering button input: 36
I (2479) I2S: DMA Malloc info, datalen=blocksize=1024, dma_buf_count=3
I (2489) I2S: DMA Malloc info, datalen=blocksize=1024, dma_buf_count=3
I (2499) I2S: APLL: Req RATE: 32000, real rate: 32000.006, BITS: 32, CLKM: 1, BCK_M: 8, MCLK: 16384003.000, SCLK: 2048000.375000, diva: 1, divb: 0

[Digital Larry]

I'm nearing the end of the road on the ESP32.  It's a fun little board but I think it doesn't have enough CPU cycles to do what I want.  It's great that I could get OSC working, but given the simplicity of the patches supported, it's not a great differentiator.  I may still keep these 2 boards I have and put them by my Eurorack stuff, just to have a flanger or a delay which is always there.  I already have a few Eurorack modules with FV-1s in them.

I'm also committed to doing things in Faust for the time being, and it's hard to tell whether this is part of the problem or not.  Their materials say "could be as good or better than hand written DSP code" but that's a fairly vague argument.

I'll probably push what I was able to accomplish on the ESP32 up to Github before too long, but I don't think I'm going to continue very far down this path.  Doesn't mean you couldn't get a nice flanger or simple echo working for not much money.

Next up, I just ordered the "Elk OS Development Bundle" for $299 which leverages a Raspberry Pi running a Xenomai RT Time kernel thing.  This seems similar to the Bela, based on a Beaglebone Black, and the upcoming Mod Dwarf.  Elk supports OSC, but I don't think the Mod Dwarf does.  I'd been using Ubuntu Studio on an old Macbook, and that is just too glitchy and hard to get latency down.  We'll see how far I get with Elk.  It's a lot more details to deal with but after all I just need stuff to keep my mind occupied.

DL

[Digital Larry]

Here's my first github checkin of Faust and C/C++ code to make a flanger on the ESP32-A1S.

In this version of the code, I have two flangers, one on either side of a fixed delay (you can set this up to about 2.5 seconds) with a little feedback. They are sweeping in opposite directions and have opposite phase shift. Take blocks out to experiment with the sound. Also there is a Faust "12AX7" block in there!  One optional line has a reverb added in.

https://github.com/HolyCityAudio/ESP32

Drill down into the faust folder to find important instructions as to how to use this.

Have fun!  Learn Faust!    https://faust.grame.fr/

DL

[Rauch]

Hi can I implement a IR loader cab sim pedal with ESP32 or with this blackstomp ? Thanks

Rauch

[Digital Larry]

Hi can I implement a IR loader cab sim pedal with ESP32 or with this blackstomp ? Thanks

Rauch

I'd say the chances of that are pretty good - at least at some level.  I just can't tell you exactly how to go about it.

[Digital Larry]

I've added code for the "echoFlanger" which is a bit like an oil can delay.  It would be more like an oil can delay if the flanger bit was inside the feedback loop of the echo.  That is left as an exercise for the reader!!!! (hint: you can't do it with ef.echo() as the feedback is self contained).

https://github.com/HolyCityAudio/ESP32/tree/master/faust

DL

Check out the Faust libraries:  https://faust.grame.fr/tools/editor/libraries/doc/library.pdf

[Digital Larry]

Here's a "basic echo" which includes an adjustable low pass in the feedback loop.  For this one I decided to use the sdelay() function, which does not pitch bend when you change the delay time.  Call me old fashioned, but I actually like delay time changes with pitch bend.  Fortunately there's another delay type you could try.

This is just a few lines of Faust code, most of which describes the parameter controls.

Code Select Expand


import("stdfaust.lib");
echoTime = hslider("[7]echoTime", 0.10, 0.10, 2.5, 0.01) : si.smooth(0.99995);
echoFeedback = hslider("[7]echoFeedback", 0.0, 0, 1.0, 0.01) : si.smoo;
echoLPF = hslider("[7]echoLPF", 2500.0, 1000.0, 10000.0, 0.01) : si.smoo;
//=============================================
process = _,_ : + <: _,(( + : de.sdelay(ba.sec2samp(2.5), 1024, ba.sec2samp(echoTime)) : fi.lowpass(2,echoLPF)) ~* (echoFeedback)) * 0.5 :> _ <: _,_;


The Faust delay library can be found here:

https://github.com/grame-cncm/faustlibraries/blob/master/delays.lib

Here I've supplied a link right to the Github code.  The state of documentation and tools in Faust world is "all over the place" as it is an academic rather than a commercial project.  Sometimes you have to dig into the libraries as there is no suitable documentation elsewhere.

As with the first two patches I put up, this uses the 6 available pushbuttons on the ESP32-A1S audio dev board to do up/down adjustments on 3 parameters, which I find is barely acceptable for a lot of things.  For example on this one, I have

- delay time (100 msec - 2.5 seconds)
- delay feedback (which can go over 1, look out!)
- low pass frequency

So there's no delay mix control.  I also have this set up over by my Eurorack stuff, where hands on real time parameter control is way more of a consideration than it is with guitar pedals, for the most part.  I may wind up attaching a couple of these boards to the side of my 19" rack tower, next to my FV-1 dev board, just to have another "thing" to run sounds through, that only does one thing.

https://github.com/HolyCityAudio/ESP32/tree/master/faust/basicEcho

I think next up I'm going to expand this delay to include a high pass in the loop and maybe an adjustable overdrive but the big deal will be the introduction of Wi-Fi connectivity and OSC, so you can bust out of the limitations of only having 3 parameters to adjust with little push buttons.

Anybody trying these?  Any questions or problems?  I realize it takes a bit of perseverance to get everything set up, and maybe Faust is not your cup of tea, but this stuff makes me relatively giddy with power (within the limits of the ESP32 itself).

DL

[Digital Larry]

Here's a delay combined with two flangers (one in the feedback loop), controllable by the ESP32-A1S audio dev board's buttons (3 parameters up/down) as well as OSC over WiFi (7 parameters - the phase buttons aren't hooked up yet).  See the readme file for important details about how to build this as it's more complicated than the earlier examples I posted.

https://github.com/HolyCityAudio/ESP32/tree/master/faust/flangerOSC

https://github.com/HolyCityAudio/ESP32/blob/master/faust/flangerOSC/flanger-osc.JPG

What's interesting is that I can't add even a single pole lowpass, fi.lowpass to the patch without getting watchdog timer errors, but I could add another flanger and triangle LFO.  So, it's a trial and error process to see how much you can jam into a single patch.

[dschwartz]

i read somewhere that the FPU on the esp32 is deactivated by default, and when called in, it takes some time to initialize, causing issues. The solution was to initialize the FPU engine on startup (somehow, i don't know)..

maybe that's causing the watchdog errors..

[Digital Larry]

I can't say that that's not the cause, but I know that adding "too much" code will certainly cause watchdog timer errors.  I'll look into it.  Thanks.

DL

[pruttelherrie]

I think a graphical tool is the way to go most of the time, but that's just me.

I second that. I really like tinkering with algorithms in SpinCAD. Writing bare metal code, not so much.

Now on to the issues I'm encountering: so I soldered a blackstomp board and started with the bare Arduino-style pass-through program. (I'm using VSCode+PlatformIO on Linux, by the way). All well. Next up was a simple delay, fixed parameters mix and feedback. Still all well, works and sounds ok, like a digital delay. Then I tried to get some filtering going, borrowing code from Rakarrack, and got stranded pretty fast. And I got fed up with the bare metal coding pretty fast as well.

So I started to look into this codebase: https://github.com/macaba/ESP32Audio/
It's a fork of the Teensy Audio Library, modified for the ESP32. I figured, if I get that up and running, I can add some blocks which aren't ported yet myself (not nice) and use these blocks in the GUI (nice).
Two things had to be done first: (1) add AC101 support (2) recode Arduino-style since Macaba's code is for ESP-IDF.
I think I got somewhere, I got stuff compiled and uploaded, BUT:

* No output. I think I'm doing something wrong with the codec initialisation or so.
* I am unable to pin the audiotask to Core1. xTaskCreate() works (as in: code *after* the call gets executed, so the task gets created) but xTaskCreatePinnedToCore() does not work. I do not understand why.
* I'm getting watchdog timeouts when the audio task is as follows:

Code Select Expand

void audioTask( void * parameter ) {
  AudioStream *p; 
  for(;;) {
    p->update_all();   
    esp_task_wdt_reset();
  }
}

However, if I add Serial.print("."); to the task, I do not get watchdog errors. I added the esp_task_wdt_reset(); myself, this was not in Macaba's code. Again, I do not understand what's going on.

But it brings me to the following:

I know that adding "too much" code will certainly cause watchdog timer errors.  I'll look into it.  Thanks.

Could this have something to do with where in the Faust-generated code the WDT is reset?

Anybody any idea where to go from here?