MP3-Player Lib, with example

I am, with respect to our 16Mbyte of flash you might double the storage without sacrificing quality, in the first instance.

But it is dependant on CPU load.

Although my SDCard is far bigger than I need so in that respect, from SDcard, I think the applications might be limited.
 
Is anybody interested in * .flac ?

Yes. At least 3 people I can recall have asked for flac. But they might also be people who wanted "audiophile" features, like 24 or 32 bit data and 192 kHz sample rates. I've heard so many requests for so many features over the last year, it's hard to keep them all in mind.

If the CPU usage is moderate and easier to break into 2.9 ms chunk, Flac could also be really compelling to use with SPIFlash, where only 16 Mbyte of storage is available.
 
It is also worth considering that flac can support any bitrate and frequency so could have applications for short samples using wav2sketch (or flac2sketch), sitting between 8bit u-law and 22khz mono.

If wav2sketch supported flac it is conceivable one could offer a full drum kit in sketch ram @22khz 16bit without resorting to 8bit u-law which would sound a lot better.

I don't think your efforts would be wasted long term.
 
mp3 and especially aac theortically support a whole bunch of bitrates..unfortunately we can only play 44.1. Now.
Maybe this changes sometime (I'll look at this, maybe in summer. Maybe a fast bitrate-converter, at minimum for 11khz and 22khz which should be easy)

Ok, i'll do first *.flac, then support for different sources (sd, additional flash, and streaming). Is Apple lossless of any use ? I found some sources, but hav'nt looked at the License..
 
I think FLAC would be enough for now, I use ALAC but only because I have apple devices and iTunes doesn't support FLAC.
 
I think FLAC would be enough for now, I use ALAC but only because I have apple devices and iTunes doesn't support FLAC.

Isn't there a way to stream ALAC from ipad/iphone ? Or is it encrypted in this case ?
If not, maybe I would be interested . Unfortunately, I have currently no information yet . Who knows more ?.

p.s. has anyone tried *.aac ? with high bitrates, i bet you hear no difference to lossless. and it's smaller... ;-) ok..needs much ram, that's the downside.
p.s.s. looks good with flac. compiles without errors now (after i have fixed some things..;-))
 
Last edited:
Yes, AirPlay is what you refer to, and there is working open source code within XBMC.

It's true that high bitrate AAC is very good, and no audiophiles have had the patience to try and beat double blind tests against it.

But I have a 4tb mirror drive on my NAS, and don't see why I should compromise quality when space is abundant :D
 
Yes I have a NAS too :)

Ok.. then, i can assume, that Airplay is not encrypted in every case. Maybe i'll look at the XBMC source when i have flac running.
My wife has an ipad , I hope that I can borrow it ;)

p.s. I hope your *.flac are 16 Bit 44.1kHz... :)
 
Last edited:
:mad:

We have a problem.
Currently FLAC wants too much RAM... i don't know why.
a) it's normal
b) It's a bug whith "Flacie" (i used this, not the Original flac-lib)
c) ...??

Then, i'm using the Teensy 1.21beta.
The last malloc() which is called does not return (at this point, more than 32K are already allocated). I don't have the source, so i can't look at this. But i think, there is not enough RAM and something breaks... i will check this..
 
Noobish question :

I downloaded the git zip, extracted in my libraries folder, loaded the Mp3FilePlayer example and got those errors while compiling :

In file included from D:\Projets\_SVN_\Dev\Arduino\libraries\Teensy-Codec\aac.cpp:24:0:
D:\Projets\_SVN_\Dev\Arduino\libraries\Teensy-Codec\aac/imdct.c:48:1: error: 'erte' does not name a type
In file included from D:\Projets\_SVN_\Dev\Arduino\libraries\Teensy-Codec\aac.cpp:24:0:
D:\Projets\_SVN_\Dev\Arduino\libraries\Teensy-Codec\aac/imdct.c: In function 'int raac_IMDCT(AACDecInfo*, int, int, short int*)':
D:\Projets\_SVN_\Dev\Arduino\libraries\Teensy-Codec\aac/imdct.c:573:127: error: 'DecWindowOverlap' was not declared in this scope
 
Noobish question :

I downloaded the git zip, extracted in my libraries folder, loaded the Mp3FilePlayer example and got those errors while compiling :

oops..
delete the line with "erte".

i don't know where "erte" comes from.. :)
i'll update the github this evening.
 
ok..before this last malloc(), FreeRam() reports -10828 Bytes

Tried the official version (edited hours... 1000's of warnings away, found a bug: #pragma GCC diagnostic ignored "-fpermissive" is ignored by the compiler)
The same.

Ok... something for the next Teensy, i think :mad:
Flac maybe is fast, but the ram-usage is...:confused:
 
Tried the official version (edited hours... 1000's of warnings away, found a bug: #pragma GCC diagnostic ignored "-fpermissive" is ignored by the compiler)
The same.

Ok... something for the next Teensy, i think :mad:
Flac maybe is fast, but the ram-usage is...:confused:

It think,it could work with a smaller framesize.
Standard-Framesize of Flac is 4096 samples, all of my files have this.
I converted a few to a framesize of 512, now it seems that we have enough memory... the downside is, that you have to convert the files.
Tool-Download: http://downloads.xiph.org/releases/flac/

Ok , now I can go on...

Edit:
First test:
With 2 Channels (stereo), Framesize 512, the decoder needs 2ms. This includes reading from SD.

For a first working version, i'll choose framesize=128, because i need no additional buffer-handling. the compression-ratio is not as good as with 512, but i plan to support other framesizes in the next versions.
 
Last edited:
FLAC is working - currently only 128Byte Blocks (see above)
I've uploaded it at Github, + minimal player example + example flac-file.

Comments welcome.

It's the very first (a bit experimental) version.
It needs much more time than mp3 or aac, because it reads much more from SD. I hope it's more useful when reading from flash.

Edit: with this small blocksize, the RAM-usage is very low, around ~10KB
 
Last edited:
Yeah, i'm also interested in FLAC playback indeed. I should try out your latest experimental version soon, I just got too many other projects running at this board :), I just bought a second teensy3.1 from Velleman, toobad Velleman doesnt sell the audioboard yet, though they said soon at the next year.

like above said, I have also have a lot of flac files laying around, just because of the better soundings, though most of them are 44~48khz.

my current solution is using PWM output and the dac output, but there's alot of difference on the sound output. sounds like one output is inverted and not always in sync :), so it sounds like you are moving phases a few degrees over time. but thats not your code!

But awesome that you bring these decodings to teensy!
 
Yeah, i'm also interested in FLAC playback indeed. I should try out your latest experimental version soon, I just got too many other projects running at this board :), I just bought a second teensy3.1 from Velleman, toobad Velleman doesnt sell the audioboard yet, though they said soon at the next year.

like above said, I have also have a lot of flac files laying around, just because of the better soundings, though most of them are 44~48khz.

my current solution is using PWM output and the dac output, but there's alot of difference on the sound output. sounds like one output is inverted and not always in sync :), so it sounds like you are moving phases a few degrees over time. but thats not your code!

But awesome that you bring these decodings to teensy!

Hi, maybe you can buy one from exp-tech in Germany: http://www.exp-tech.de/teensy-audio-adaptor-board?gclid=CIv5rZ6J18ICFdQZtAodg3oAHA
 
Hi,

the Teensy FLAC-Codec now supports:

- Blocksizes from 128..1024 bytes, in 128-byte steps (for example 128, 256, 512...)
- 4..24 bits per sample. For 24 bits per sample, blocksize 512/stereo is maximum (because of memory-usage). All are "on the fly" converted to 16 bps for the audio-library.

You can save (very!) much RAM with smaller blocksizes. The downside is a slightly worse compression-ratio (-> the codec has to read more from sd!)

It's now full functional. For those, who like to experiment: there's a switch which lets you choose if decoding is done in a additional software-int or in the originl 2.9ms audio-lib int. Because of SD-accesses, the default (additional swi) is better at the moment. This may change when playing from flash is available.

I got the serial-flash from china now. I hope my eyes are good enough to solder it to the board.... :)
 
Last edited:
Next:
- Playing from teensy-flash & serial flash.
- improvements to the internal structure of the lib

Done.

I feel I have to write a documentation.... any volunteers ? :)

In short :
- play(filename) plays from SD
- play(int position, int size) plays from Serial Flash (Audioshield) There's a tool in "examples" to fill the Serial Flash with files from SD.
- play( (uint8_t*), int size) plays from Teensy Flash (a short example is in the "examples directory"). Use a tool like https://code.google.com/p/bin2h/ (for example) to convert music-files to *.h

It's amazing how much fits into the flash of the Teensy, especially if it is AAC-encoded.

New plan: Try to play multiple files simultanous.. mixed mp3/aac/flac or flac only (from flash). But i don't know when i have time to do it.
 
Last edited:
i was just trying out to play a mp3 from the Serial flash, but it seems to get stuck (or, more likely, I'm doing something wrong).


i've copied a few mp3s into the flash, and took down the position and length info. that worked.

for instance:

size_t pos = 0x0;
size_t len = 44287;

in the Mp3FilePlayer Example, all i did was change play(filename) to play(pos, len);

it compiles fine (as long as I use "size_t" for the position and size), but there's no audio and it looks as if calling play(pos, len); crashes the program (there's no repeated calls to "play"). any hints?
 
Back
Top