http://www.esp8266.com/viewtopic.php?f= … =40#p21048
Victor ? are you the same Victor “pvvx” author of this work on ESP ?
If Yes, do you plan to port some of this work to the STM2duino ?
Ciao ! ![]()
But I have done nothing about it except download an MP3 decoder project for the STM32F4 that I intended to try to port at some point…
EDIT: I had a quick look, this looks really cool. I have a few ESP laying around that I need to put to some use…
EDIT2: had a bit better look, I don’t think this should be difficult to port at all. We could use 2 channels of a single timer to do PWM output. We have freeRTOS and CoOS working already.
@matthias, our audio expert, what do you think about that ? do you think is is worth to have it ported ?
This is the most interesting part for me: How to implement a mp3 software decoder. As I know the sw codex is much RAM intensive, so I read:
The MP3 example is a very memory-sensitive piece of code: the MP3 decoder uses almost all the RAM and the needed buffers for input and output buffering take up the rest: when using no external SPI RAM, only a few bytes of memory are left. The SDK libs that come with this example are libraries that have been optimized for memory usage and are known to work.
and further:
Support all ESP2866 modules (512 Kbytes flash)
Free Flash (512 Kbytes): 200 Kbytes. Free Heap: 20 Kbytes.
MP3-decodec-out uses IRAM Buffer > 20 Kbytes (IRAM: 48k + 16k cache Flash):
The specs for the ESP8266 are:
[*]64KBytes of instruction RAM
[*]96KBytes of data RAM
So I doubt getting mp3-sw-decoding, pwm-out plus frontend (incl. hardware like display…) working on a medium-density device. It’s more a job for the high-density ones – and they have I2S on board, so no fooling around with PWM-delta-sigma audio would be necessary (I2S DAC’s costs about a few cent up to 2-3 USD).
So maybe using the PWM-delta-sigma code for something else than mp3 (or any other compressed audio format) like speaking alarm clocks,…? This should be possible!
Off topic:
A really impressing demo of what can be done with pwm-audio (using 2 pins) even on AVR’s is the outstanding mozzi library:
http://sensorium.github.io/Mozzi/
VS1053 boards are less than $10, and we have a lib for them (thanks to vasillis)
$10 http://www.ebay.com/itm/VS1053-MP3-Modu … 4853e421c4
Offloading MP3 (or WAV etc) playback to external hardware is most likely the best option as it leaves the main processor free to do some other things
I agree if the goal is to build up a whole audio player. If you wanna use only some audio files for your project (acoustic feedback), because you are annoyed of the beeping of microwave oven, than a smart 2-pin-pwm resolution isn’t a bad idea (you only need two girls resistors and a cap):
http://sensorium.github.io/Mozzi/learn/output/
Thanks for the link to the Mozzi wiring diagram. I wondered why it needed 2 pins.
i agree. Mozzi sounds excellent, so perhaps we should port it t STM32.
i have looked at audio playback on AVR before, which used multiple pins, but it was not as clever as Mozzi. I cant remember the name of the library, but it just played beeps on multiple pins, so that you could have very basic polyphonic music e.g. like cheap musical christmas cards.
But Mozzi sounds amazing. I presume that the 2 bits, give output levels. I wonder if its scalable to more pins ?
Porting mozzi to stm32duino is a huge project, the author is a maniac (positive meaning!) Read the “Caveats and Workarounds” on front page. I’ve done a closer look at the code and there is much low level content. There was a plan for porting the lib to DUE, but I think the author stopped that, because of teensy support. So a port to STM32 is possible, but you need to look into many *.h and *.c files, because there is sadly no common hardware setup file, as you can see on the many #ifdefs for teensy. No problem should be to rewrite the timer libraries (maybe a good idea to rewrite/wrap the prjc timerX libraries at all, they are nearly “standard” ).
I don’t think there is much benefit in scaling more pins, because even for 14 bit dualPWM you need a resisior accuracy of 0.78% (see the table in the openmusic document) and for triplePWM you’ll get in serious troubles matching the resistors at all! So mozzis 14bit for hi-res audio is honestly and trustworthy, everything else (above 14bit) would be a sham and waste of resources.
<…>
the author is a maniac (positive meaning!)
According to NXP application note:
1.7 Memory requirements
The EFSL and the libmad libraries consume memory to work. The amount of the memory
is about:
Table 1. Memory requirements for the MP3 player demo
RAM [kB] Code [kB]
Libmad + EFSL 33 109
I found it in the link to one of the taobao boards. It was a board with 64KB, not sure how much of that it comsumes:
http://pan.baidu.com/share/link?shareid … =506725102
I haven’t look at the details yet, so no idea if it uses the DACs in that chip, or the i2s (may be the case…).
Any way, whenever I have a chance I’ll test this out in one of my RCT6 boards, as those actually have 64KB of ram, so should be enough.
This may be a good option for many, as those boards can be had for the same price as a VS1003 or less, and instead of 2 boards you use only one and a little amplifier.
viewtopic.php?f=15&t=2936&p=38022&hilit=mozzi#p38022

