MP3-Player Lib, with example

Frank B

Senior Member
EDIT : Plays from SD, Flash, Serial Flash
EDIT : added FLAC-Support (Blocksize max 1024, 4-24 Bits)
EDIT : Last Version: now as Audio-Library-Object usable. With AAC.
EDIT : Renamed to Arduino-Teensy-Codec-lib



Hi,

i wrote a lib for teensy 3 which is able to play mp3.

https://github.com/FrankBoesing/Arduino-Teensy-MP3-lib
There's an example too.

It plays mono/stereo mp3 files from sd-card,
up to 320kbps, 44.1 khz, 16 Bit with good quality
with Pauls famous Audiolib.

Later, i'll extend this to more formats like aac (maybe aac+), flacc, etc.
But feel free to do push-requests :)

Tests are very welcome...

Regards, Frank.

p.s. I deleted the old, quick,dirty&buggy example at github.
 
Last edited:
There's surely some hardware other than the bare teensy involved. I had a look at the repo, but couldn't find a schematic. Is it just the audio board?

Apart form that - awesome! I'll try to find some time to test it.

Regards

Christoph
 
No... ok, you need an sd-slot for the files :)

But you can use pcm or whatever as sound-output - all audio-lib supported devices.
I tested the audioboard only.
 
Is it just the audio board?

The audio library gives you a collection of audio components, which you can connect with each other. They're interchangeable. It's very easy to connect something that creates sound to either the I2S output (to the audio board) or to the built-in DAC, or to PWM. You can even wire the output to 2 or all 3.

To get a visual idea of how it works, give this design tool a try.

http://www.pjrc.com/teensy/gui/

For now, Frank's MP3 stuff uses the Play Queue object. Eventually, I want to create a dedicated MP3 decoding object... but that will take quite a lot of work to restructure the code and break the CPU intensive part into sub-tasks (eg, divide up the polyphase filter bank) so it plays nicely. In the meantime, the Queue object is meant to allow easy development outside of the library. The queue allows bursts of data to be queued up for code that isn't structured to use CPU time the was the audio library works internally.
 
For now, Frank's MP3 stuff uses the Play Queue object. Eventually, I want to create a dedicated MP3 decoding object... but that will take quite a lot of work to restructure the code and break the CPU intensive part into sub-tasks (eg, divide up the polyphase filter bank) so it plays nicely. In the meantime, the Queue object is meant to allow easy development outside of the library. The queue allows bursts of data to be queued up for code that isn't structured to use CPU time the was the audio library works internally.

I'll look at this too (but first i want aac suppport)

Yesterday, i had the idea to do the decoding in an extra timerinterrupt. That's not really the audiolib-way, but it would be more easy and give the same result.
Paul, what do you think ?
You can take a look at the "madlib" (from linux) too, maybe this is easier to split - but i don't know if it has the same speed on our Teensy.

edit: sorry, "madplay", not "madlib" :)
 
Last edited:
Yesterday, i had the idea to do the decoding in an extra timerinterrupt. That's not really the audiolib-way, but it would be more easy and give the same result.
Paul, what do you think ?

Sure, go for it.

Eventually I want to work on really integrating MP3 into the library, but this sounds like a pretty reasonable intermediate step.
 
Yes!!!

It plays the first aac !! Seems to be a bit faster than mp3.
I have to optimize some things, (and there are some issues in the aac-decoder too), but i'll update github as soon as possible.
Maybe tomorrow.

Paul, if you want to integrate it, i can give you some tips. for mp3 for example there is a loop, which can be spilted.
Then, there are some places where some thing can be optimized for the newer cores (the lib is quite old).
AAC has for example a loop for reversering bits..
More optimizing can be done with using the DSP. But thats goes over my free time :)
 
Last edited:
Very interesting gentlemen.

I have three questions:
1) How many MP3s could you play concurrently from the same SDCard? (Of course, this uses playqueue so perhaps we can't do that yet...?)
With less bits comes less bandwidth and SDCard bandwidth is one of the limiting factors at the moment. Teensy can probably handle 64 plus mixed tracks if it could just get at the data quick enough.

2) I wonder; How easy would it be to pipe encoded .h files through instead of using the SDCard?, A-la WAV2SKETCH, instead an MP32SKETCH?

3) And how much of the CPU is being used during playback? How CPU intensive is it? Compared to say, U-law decoding (which i'm using for all my samples)

I think a lot of people are making sonic sacrifices due to the limited amounts of RAM available and using mono files, at 22khz instead of 44khz stereo etc.
I'm pretty sure I could get twice the quality from the same number of bits if I used AAC or MP3 instead, at a cost of CPU ticks of course. I wonder where the sweet spot falls.
 
Very interesting gentlemen.

I have three questions:
1) How many MP3s could you play concurrently from the same SDCard? (Of course, this uses playqueue so perhaps we can't do that yet...?)
With less bits comes less bandwidth and SDCard bandwidth is one of the limiting factors at the moment. Teensy can probably handle 64 plus mixed tracks if it could just get at the data quick enough.

2) I wonder; How easy would it be to pipe encoded .h files through instead of using the SDCard?, A-la WAV2SKETCH, instead an MP32SKETCH?

3) And how much of the CPU is being used during playback? How CPU intensive is it? Compared to say, U-law decoding (which i'm using for all my samples)

I think a lot of people are making sonic sacrifices due to the limited amounts of RAM available and using mono files, at 22khz instead of 44khz stereo etc.
I'm pretty sure I could get twice the quality from the same number of bits if I used AAC or MP3 instead, at a cost of CPU ticks of course. I wonder where the sweet spot falls.

Hi Pensive,

1,3)The lib is at a very early stage. It can only one mp3 be played at a time.
At 48MHz, the decoding takes ~16ms for 26ms audio, at 144MHz 5-6ms. Calc yourself :)
But on the plus-side is, the blocks that are read from SD are much smaller than wav, because of the high compression. Therefore, less time for that.
There is very complex math involved... and to decode these formats, the teensy hat as a lot to do. Take a look at the decode-source, its on my github-repro. My current version for both, mp3 + aac take 100k flash.. ~80% for the decoders :)
Its not compareable to u-law.

2) seems to be possible, but not at the moment.
 
Last edited:
Thank you frank; with that much sketch used for decoding code, I doubt MP32Sketch would be practical :)

I guess we must realise we have a teensy here and it cannot be all things to all men :)

Great work ;)
 
Pensive, if your mp3 is really tiny, it might fit. Teensy 3.1 has 256 kB flash, and there would surely be space for things like a 100ms long button click sound.
 
I you use aac only (the better format, higher compression, better quality, faster decoding), there is much more space.
 
Well played sir!

That puts the teensy plus audio board head and shoulders above Due plus Adafruit MP3 shield :)

The MP3 shield is monophonic ;)
 
We do. with this kind of power and capability we really need 16 or 32 megabytes.

On the plus side with over clocking, I could see 2 x mp3s playing at the same time, with effects, which means you could make a standalone DJ station with a bit of polyphony hacking :)
 
Last edited:
Paul, if you want to integrate it, i can give you some tips. for mp3 for example there is a loop, which can be spilted.
Then, there are some places where some thing can be optimized for the newer cores (the lib is quite old).
AAC has for example a loop for reversering bits..
More optimizing can be done with using the DSP. But thats goes over my free time :)

Yes, I definitely want to integrate this into the next version of the library.

Just to be realistic, it'll probably be a few months until I can do any really serious work on this. I'm currently working on new hardware, and juggling time to make small fixes to about a dozen Arduino libraries (currently nRF8001).
 
I added this to the audio lib roadmap page, with a link to this thread. Hopefully that'll help anyone interested in this to find the code and follow this development.

http://www.pjrc.com/teensy/td_libs_AudioRoadmap.html

Hi,

i have *.mp4 and *.m4a (=apple-style mp4) 90% running now... the fileformat is horror :) ( "ISO14496-14" if anyone wants to study it)

I have plans to add flac as well. I think the code/ram usage will be smaller and it should be little bit faster. If it is fast enough (have to test this), maybe encoding is possible too ?
I'll find this out...
Flac is interesting, because it is open source, lossless, and the files are 30%-70% (depends on the content) smaller than *.wav.

But first, when i have mp4 running (maybe tomorrow, (or this evening?)), i spend some time, and try to modifiy the mp3/aac/mp4/m4a codecs and build audiolib-objects.
I already took a quick look at the audiolib - i had the idea to use a software-interrupt (triggered by "update") - but i have seen, the audiolib uses it already - and teensy has only one :)
Ok, any interrupt can be triggered in software, so i use one of the others.. which one is rarely used ?
Then, the audiolib uses the lowest priority,but the decoding should use a lower priority. Would it be a problem to increase the "update"-priority on level ? I know how, but i don't know if any problems can occur.

Frank.
 
Last edited:
Hi,
i have *.mp4 and *.m4a (=apple-style mp4) 90% running now... the fileformat is horror :) ( "ISO14496-14" if anyone wants to study it)

Gotcha :)
Ok, basic functionality for mp3, mp4, m4a & aac is now given.

Great soundquality :)

Frank.
 
Would it be a problem to increase the "update"-priority on level ? I know how, but i don't know if any problems can occur.

Yes, I believe this can be done. Maybe 224 or even 208 would work?

I'm imagining a distant future where we'd want audio software interrupt running ever 2.9 ms and a video software interrupt running every 33.3 ms.
 
Does the m4a support apple's lossless out of interest?
No, and it is not planned . I plan instead to take care of the equivalent/better (faster decoding, files have less overhead) flac. But it can take some time.
It is possible to convert apple lossles <-> flac without losses.
But contributions are welcome, the m4a-parser is already there and only the audiodecoding is missing.
 
Last edited:
Back
Top