sensorium / Mozzi

sound synthesis library for Arduino
https://sensorium.github.io/Mozzi/
GNU Lesser General Public License v2.1
1.07k stars 186 forks source link

Proper system condition in mozzi_pgrmspace.h #125

Open pschatzmann opened 3 years ago

pschatzmann commented 3 years ago

While defining a new kernel I was stumbling over the following: There is a condition for #if IS_ESP8266() || IS_ESP32() and in the and in the #else we have some logic where I am not sure for which processors it applies. I would really like to have a specific list here and a proper #error in the else case so that when somebody is porting to a new environment he gets a proper error message.

Would we know what this list would be ?

tfry-git commented 3 years ago

For the time being it's really all other platforms. ESP32 and ESP8266 are special, here, because their flash memory (aka program space) is externally connected, and rather slow. On these platforms, we don't want to put wavetables into program space, while for the other MCUs that is possible and helps save RAM.

I believe on RPi there is not even any such distinction, so it probably will not matter either way.

If you have an idea who to express this in a more self-explanatory way...

pschatzmann commented 3 years ago

So your saying the else case is currently valid for

if (IS_AVR() || IS_TEENSY3() || IS_STM32() || IS_SAMD21())

I noticed that for my ARM Mbed and for the RP2040 implementation this section is compiling w/o errors - but I was clueless for quite some days why all my boards were crashing when started with Mozzi!

I think we really need to be more explicit here...after all there is this

include <avr/pgmspace.h>

which points that this is only valid for avr specific implementations...

I was double checking your statement: the wavetables are e.g. defined as CONSTTABLE_STORAGE(int8_t) which is giving const on the ESP32 and from what I know this will ends up in Flash Memory!

tfry-git commented 3 years ago

I was double checking your statement: the wavetables are e.g. defined as CONSTTABLE_STORAGE(int8_t) which is giving const on the ESP32 and from what I know this will ends up in Flash Memory!

Hm, indeed. I must have simply assumed that by analogy wit ESP8266...

As for <avr/pgmspace.h>, note that both Arduino and Mozzi originated on AVR. When arduino started supporting more platforms, most cores added (among others) avr/pgmspace.h for compatibility with existing code. By the same token, when Mozzi started adding platforms (teensy, then STM32 were the first, AFAIK), there was no need to touch this part. The arduino ESP8266 core also has avr/pgmspace.h, but it does suffer from slow flash (as I had also assumed for ESP32), which is why the #if came into being (IIRC, there wasn't even a separate mozzi_pgmspace.h, before).

Now, you are probably right that at least some of the platforms in the #else portion could (and should, for clarity) be moved up into the #if section. Their pgmspace macros will simply work on const types. But of course that would need to be sorted out very carefully.

but I was clueless for quite some days why all my boards were crashing when started with Mozzi!

But why did they?

pschatzmann commented 3 years ago

It'seems that I was jumping to a conclusion which did not hold. I am happy to confirm that this is not the source of my crashes. So far I did all my audio projects on ESP32 - and this is the first time I am working on any ARM Mbed based boards. I just assumed that they are in the same ballpark like the ESP and hell was I wrong.

So I started to do some measurements:

Function Nano 33 Sense ESP32 Pico MBed Nano AVR
aSin(SIN2048_DATA) 27'000 780'500 27'000 115'000
Output of 1 Pin 53'000 NA 53'500
Output of 2 Pins 38'000 NA 44'500 153'000

I seriously starting to doubt if this is leading to anything useful - when a old AVR Nano is more then 4 times faster then a Nano 33 BLE Sense...

gnodipac886 commented 3 years ago

@pschatzmann I was just wondering how you were able to get mozzi to work with a nano ble sense?

thanks in advance!

pschatzmann commented 3 years ago

Sorry for my late update, but I was working on some other projects. I got most of the compile issues resolved now and MBED devices (RPI and nano BLE) are producing sound now. I didn't do any extensive testing yet, and I know that USE_AUDIO_INPUT true is creating compile errors...