Ogg Vorbis decoding with STM32F103RE works!

Posted on May 17, 2011 at 12:53

Dear Mark,

Excellent news and Great to Job for your port as well !! STM32 is designed to release your creativity :)

Can you share your project with others Forum users ? so we can may be enhance it by special hand made optimization.

Cheers,

STOne-32.

Posted on May 17, 2011 at 12:53

I was looking for this sort of information before I started, but was unable to find it. I figure that this may be worth posting for the next person who might be looking.

I have 22050 KHz stereo ogg vorbis decoding on a STM32F103RE, running at 48MHz. It suffers from some very minor popping at 32MHz -- with some tuning I could probably get that to work. With full PLL, I'm sure 44100KHz is possible, but I don't need that for my application.

I used the ''Tremor'' integer math reference decoder (http://svn.xiph.org/branches/lowmem-branch/Tremor/) and GCC (CodeSourcery G++). The DAC is a TI TLV320AIC23B, and the ogg files are stored on a MMC card. Decoded PCM data is buffered in SRAM and fed to the I2S peripheral with DMA transfers.

Overall, I am very happy with the STM32 cortex-m3 processors. Good job!

Mark

Posted on May 17, 2011 at 12:53

Hi Mark,

Nice one. If you are using the MMC are you decoding from a filesystem, or linear data block. If it's filesystem, just out of interest whos filesystem code are you using?

After playing with MP3, I did this a few months back with the STR9 using the tremor branch, and efsl (FAT16 filesystem). However, as I did not use an RTOS and make the most of the SD card fetch time, I ended up wasting cycles on the SPI (file read) which caused some gapping as the CPU could not quite keep up.

I am in the process of re-writing this with FreeRTOS, but I have also been drawn away by eCos / eCosCentric, who have released support for the STM32. So I am considering using this as it has built in filesystem support.

Martin.

Posted on May 17, 2011 at 12:53

Quote:

On 20-11-2008 at 13:58, Anonymous wrote:

Hi Mark,

Nice one. If you are using the MMC are you decoding from a filesystem, or linear data block. If it's filesystem, just out of interest whos filesystem code are you using?

After playing with MP3, I did this a few months back with the STR9 using the tremor branch, and efsl (FAT16 filesystem). However, as I did not use an RTOS and make the most of the SD card fetch time, I ended up wasting cycles on the SPI (file read) which caused some gapping as the CPU could not quite keep up.

I'm not familiar with the

I am in the process of re-writing this with FreeRTOS, but I have also been drawn away by eCos / eCosCentric, who have released support for the STM32. So I am considering using this as it has built in filesystem support.

Martin.

To STOne-32: Sadly, I am not at liberty to release my code. :(

Martin:

I am using the ELM FatFs library. (http://elm-chan.org/fsw/ff/00index_e.html) It looks like it is either the same or very similar to EFSL. I've had no trouble with the MMC SPI access keeping pace, although I agree it is somewhat wasteful. Since the STM32 I am using has 64K of RAM, I buffer 2K of the file before I start playing.

I'm not familiar with the STR9, but with the STM32 DMA transfers were immensely helpful. I think I would have trouble keeping up otherwise. Also, did you use the tremor low-mem branch?

Mark

Posted on May 17, 2011 at 12:53

Hi Mark,

Interesting, yes I did use the low mem branch. Tremor seems to work by dynamically allocating buffers all the time, and using the normal one I soon ran out of memory. Although it needs more CPU power to use lowmem.

Yes DMA is immensely useful, while playing back a decoded audio buffer, you can be decoding the next packet into another playback buffer. I would have also like to use DMA on the sector read command, which obviously using an RTOS could be done, thread only needs to wake up when DMA terminal count interrupt arrives, leaving the CPU to work on those intensive decode routines.

The other thing I started was porting the math routines to use the STM32 MAC. Did you do this in your port?

Martin.

Posted on May 17, 2011 at 12:53

Quote:

On 20-11-2008 at 16:15, Anonymous wrote:

Quote:

On 20-11-2008 at 13:58, Anonymous wrote:

Hi Mark,

Nice one. If you are using the MMC are you decoding from a filesystem, or linear data block. If it's filesystem, just out of interest whos filesystem code are you using?

After playing with MP3, I did this a few months back with the STR9 using the tremor branch, and efsl (FAT16 filesystem). However, as I did not use an RTOS and make the most of the SD card fetch time, I ended up wasting cycles on the SPI (file read) which caused some gapping as the CPU could not quite keep up.

I'm not familiar with the

I am in the process of re-writing this with FreeRTOS, but I have also been drawn away by eCos / eCosCentric, who have released support for the STM32. So I am considering using this as it has built in filesystem support.

Martin.

To STOne-32: Sadly, I am not at liberty to release my code. :(

Martin:

I am using the ELM FatFs library. (http://elm-chan.org/fsw/ff/00index_e.html) It looks like it is either the same or very similar to EFSL. I've had no trouble with the MMC SPI access keeping pace, although I agree it is somewhat wasteful. Since the STM32 I am using has 64K of RAM, I buffer 2K of the file before I start playing.

I'm not familiar with the STR9, but with the STM32 DMA transfers were immensely helpful. I think I would have trouble keeping up otherwise. Also, did you use the tremor low-mem branch?

Mark

I tryied the ELM FatsFs, but during the debugg go to a hardFault exception. I'm using Spi too, and the STM32F103RBT6.

Do you have any exemple of this part, the implementatio ELM FatsFs in STM32 with spi?

I searched in the internet and this information lacks, just found for avr, lpc, H8 and pic.

In this forum just send-me 2 codes that does`t work and use SDIO not SPI.

Can u help me and share some example? I don`t want your code, just a exemple to use ELM FatsFs in STM32.

Thanks,

Vinicius

Posted on May 17, 2011 at 12:53

Just a quick follow-up. I had an extra digit in my systick configuration, which I was using as a simple timer. Once I removed the digit, my MMC transfers are much much faster and I am easily able to keep up with 44.1KHz ogg files now.

Awesome!

Posted on May 17, 2011 at 12:53

This should be a good starting point:

http://www.st.com/mcu/forums-cat-6318-23.html&start=10

I'm using CodeSourcery G++ if that makes a difference. I had to take special care to make sure that I linked with the -mthumb switch or the linker would link in the non-thumb versions of memset, etc.

Mark