-
Hi,
I want to try Decoding MP3 on this part, do you recommend any light weight opensource library?
-
Just keep in mind that there is no chance Cortex-M0+ at 64 MHz can decode MP3 in real time for playback.
-
Just keep in mind that there is no chance Cortex-M0+ at 64 MHz can decode MP3 in real time for playback.
Well well. Probably depends on the compression level and the target sample rate. While it does seem pretty challenging, I wouldn't necessarily say "no chance" upfront. But that would certainly require significant work and probably a good chunk of assembly to get it to work. Not sure it's worth the trouble.
-
There're mp3 decoders using fixed point math.
While not 100.000000% accurate, they do the job -
But they still need quite a bit of performance to do real time decoding.
Sure, you can artificially create an mp3 file that is bad enough to be decoded on Cortex-M0+, but that does not represent a typical use case. -
IIRC 48MHz where more than enough on an optimized arm system.
Helix is fixed point -
Quote
This one uses helix mpr decoder:
Thanks david, But it uses some asm functions that are only supported from Cortex M3 upwards.
https://github.com/lamilami/stm32-mp3player -
Quote
Just keep in mind that there is no chance Cortex-M0+ at 64 MHz can decode MP3 in real time for playback.
Thanks Alex for the tip, But I want to do some lower bitrate MP3 files, I think it would be possible. -
Quote
I have used this:
Thanks brichards42,Did you use it on an embedded Part like ARM Cortex? since I take a brief look at the minimp3.h file and see some asm functions.
https://github.com/lieff/minimp3
I found the author very helpful. -
I have compiled the code for M3 minimp3 and it would compile fine, But for M0 it would complain about this ASM function,
I have started a new thread here,
https://www.eevblog.com/forum/microcontrollers/converting-to-cortex-m0-asm/
brichards42 Have you done it for M0 or do you suggest rewriting it for M0?
-
On my project I was using a STM32F446RET. I don't recall using any asm functions (it was several years ago), but maybe it can't work on a M0, sorry.
-
A tiny remark, the M0 and M0+ have two options for the hardware multiplier: a fast and a small one.
Fortunately, the STM32G070 has a M0+ with a single-cycle multiplier, so all hopes are not lost. If it had the "small" multiplier option, that would be a 32-cycle multiply, and then forget about it.
Of course you need to use an integer/fixed-point decoder. It has no FPU either, so any decoding using floating point would be catastrophically slow.
-
But they still need quite a bit of performance to do real time decoding.
So what would be a typical use case for mp3 in a small microcontroller?
Sure, you can artificially create an mp3 file that is bad enough to be decoded on Cortex-M0+, but that does not represent a typical use case.
It's unlikely to be a HiFi quality audio player.
I'd say typical use for MP3 in a small microcontroller would be from doorbel chimes to sections of voice for an phone-connected alarm system.
I'd say that low / medium quality mono audio would be a much more "typical" use of mp3 on a small uC then full blown HiFi stereo.
I do wonder why the document below mentions patents and royalties.
https://datasheet.octopart.com/STM32-MP3NL-DEC-STMicroelectronics-datasheet-16349441.pdf
MP3 is well over 20 years old and patents have expired.
But does it have to be MP3? OGG-vorbis has always been license free and is quite comparable to MP3, and there are hundreds more specialized codecs for more specilized codes tuned to for example use cases such as voice.
-
I do wonder why the document below mentions patents and royalties.
Patents expired 6 years later than when document was created. https://www.iis.fraunhofer.de/en/ff/amm/consumer-electronics/mp3.html
https://datasheet.octopart.com/STM32-MP3NL-DEC-STMicroelectronics-datasheet-16349441.pdf
MP3 is well over 20 years old and patents have expired. -
So what would be a typical use case for mp3 in a small microcontroller?
I would say the only justifiable use of MP3 in this case is you accept user files from an SDCard, for example. But in that case requiring very strict compression and quality settings is not going to work. It is much easier to just ask people use uncompressed wave files, especially given the minimal size of the cards you can get.
If you are using it with predefined files where you are in control, then there are easier do decode compression algorithms. -
But does it have to be MP3? OGG-vorbis has always been license free and is quite comparable to MP3, and there are hundreds more specialized codecs for more specilized codes tuned to for example use cases such as voice.
I believe decoding OGG Vorbis requires more computational power then decoding MP3, therefore considering the target is a Cortex M0, I'd say MP3 has an advantage over OGG Vorbis. -
You could also consider a dedicated IC such as the VLSI VS10xx series. Some support MP3 and Ogg vorbis. Dead easy to use. Of course, that's an extra cost, but only requires minimal CPU from the MCU to feed it with data. The CPU can do other things too. Unless you're using a pretty powerful MCU, if you manage to decode MP3 in real time, it's likely not going to be able to process anything else much.
-
Is there a compression algorithm that does somewhat better than phone-quality audio with less computational complexity it the decode phase?
(Keeping in mind that a $5 sd (4GB) card holds like 5 hours of cd-quality music with NO compression.)
-
The Sandisk Sansa Clip music players used a SoC from AMS (Austria Micro Systems) which ran at around 40 or 48 Mhz if my memory is correct... installed Rockbox on it and played Opus and FLAC on it just fine. But, I think the SoC had some extra hardware decoding functionality.
As for is there a compression algorithm with less computational complexity ... I would investigate if the old AC3 and mpeg 1 layer 2 (or whatever was used in Video CD / SVCD and old SD satellite transmissions) are lighter, as the patents expired for them ... both would use more bitrate to get same quality as MP3 but should be a bit easier to decode.
I know of libMAD , a mpeg decoding library which does everything in fixed point so it may be suited for conversion to microcontrollers
This page has a bunch of projects and mentions using libMAD with Arduino but the examples in the page use helix : https://www.pschatzmann.ch/home/2021/08/13/audio-decoders-for-microcontrollers/
Found this appnote / document which shows using libMAD and LPC2148 but that's ARM7 chip and kind of expensive at around 15-20$ : https://www.nxp.com/docs/en/application-note/AN10583.pdf
Maybe could be used with a microcontroller that has less memory and storage and more reasonably priced.
but browsing the appnote they still had to tweak it a bit to fit in the 32 KB of ram the microcontroller has, and they only used mono mp3 files because there's only one built in DAC. Not sure if the chip had enough processing power to do two channels.
edit : Ah, on page 23 it says :
Libmad is a well-known library to decode MP3 files. Libmad is also used in the popular
free VLC player, however, as you can see in the last table, the porting of the actual
version of libmad on an ARM7 (@60 MHz) loads the CPU from the 40 % to 70 % of its
power, so only one audio channel can be decoded in real time. Browsing the web we
found one interesting alternative represented by the Helix MP3 Decoder suitable to
decode, in real time, a stereo MP3 stream. Additional audio codec is also available, like
AAC. All these codecs have a specific RCSL and RPSL license. For more info about this
codec please refer to: -
Quote
All these codecs have a specific RCSL and RPSL license. For more info about this
There is no link
codec please refer to:
-
Even without hardware decoders ARM7 has a lot more performance compared to Cortex-M0+.
-
Quote
All these codecs have a specific RCSL and RPSL license. For more info about this
There is no link
codec please refer to:
Links are in appnote but they redirect to a dead page on helixcomunity .. this was the page redirecting to in 2017
https://web.archive.org/web/20171123171114/https://www.helixcommunity.org/projects/datatype/Mp3dec
-
I thought a bit more about it, and I think you should turn it around.
If you want to be able to decode and play MP3's, then first go fetch a library that can do it, and then choose a uC that can do it relatively comfortably. If you go squeezing pennies and go for the smallest uC that should sort of be able to maybe do it, then it's quite likely you spend an exorbitant amount of time on tuning the software or fabricating audio files that are quick enough to decode, and this is only cost effective if you plan to sell really big numbers of devices, and even then it may be best to get to market quick with a "too big" uC, and get some experience with MP3 decoding in the beginning, and then later downscale to a smaller uC.