The ST Firmware for STM32F4 Discovery includes a simple Audio demo that
demonstrates a Wave player (directory Project/Audio_playback_and_record).
From that project, I derived an Audio_playback_MP3 that plays an embedded MP3
stream (the same audio as in the ST example), but the audio is now around 55 seconds
instead of the original 5 seconds.
The MP3 decoder lib used is the libmad v. 0.15.1 .
I created a new GCC sub-folder, since I am using no specific IDE (only gcc version 4.5.2 (Sourcery G++ Lite 2011.03-42)).
Simply put the provided source in the ‘Project’ folder.
Then go to the ./GCC folder and use ‘make’.
Some sources were taken/derived from ChibiOS (chprintf/makefile/rules.mk).
[ For some reasons, audio initialisation was a bit tricky, and that page helped
me : http://homepage2.nifty.com/yees, with the TTS on STM32 project. ]
For debugging, USART2 was used (pin PA2), with Bus Pirate in UART bridge mode
(38400/8/N/1, only PA2 is used, nothing is sent to the STM32).
Bus Pirate v3.a
Firmware v6.1 r1676 Bootloader v4.4
DEVID:0x0447 REVID:0x3046 (24FJ64GA002 B8)
http://dangerousprototypes.com HiZ>m ...
Set serial port speed: (bps)
Data bits and parity:
1. 8, NONE *default
1. 1 *default
1. Idle 1 *default
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
Reset to exit
Are you sure? y
SetAudioInt : 0
AudioInit : 0
MP3 in : lg 879457
decoding error 0x 101 (lost synchronization) at byte offset 0
Malloc 2567 (20005AA0,10000)
Calloc 1152 4 -> Malloc 4608 (200064B0,7424)
MP3 in : lg 0
Decoding return 0
Source code : Audio_playback_MP3.tgz
The tgz includes the .hex or .bin files (./Binary folder) that you can use to test directly on the Discovery board without compiling.
Note: From Linux, I have also used this guide : stm32f4-discovery-board-with-linux
to use Texane/Stlink , more particularly the ‘flash’ command
( stlink/flash/flash write ./build/audio.bin 0x8000000 ).
Update : I was asked what was the CPU usage to decode MP3 at different bitrates.
I made tests with 128kbps (included in the source) and 320kbps (‘lame –preset insane’) and since the code
is not optimised for Cortex-M4 (yet…) the results do not vary a lot : it is around 20% CPU usage.
OLS capture at 128kbps
OLS capture at 320kbps