AnsweredAssumed Answered

MP3 Decoder library problems

Question asked by iceburn on Oct 27, 2011
Latest reply on Nov 10, 2011 by SimonB
Branched to a new discussion


I have problems with the latest MP3 Decoder library (v3.1.1) on BF532.

I'm using 2 intances, the first using 1MByte buffer and the second 128kBytes buffer.

All the state, scratch and buffers are in SDRAM, all MP3 library and wraper code are in SDRAM too.

Both L1 data memory banks are cache, L1 program cache is on.


The first instance plays a continuous Internet stream.

The second is used to play backup mp3 files from SD card.


The decoder is actually working, but causes some issues.


This is the code flow:

1. create and configure the instance

2. fill in some data in the input buffer (more than 10kBytes)

3. search for start of frame (using self written function as the MP3 Decoder programming guide requires)

4. call adi_mp3_decode for the first time

5. fill some more data in the buffer

6. call adi_mp3_decode again

7. repeat 5&6


The strange behavior begins when calling adi_mp3_decode for the first time. The returned result is ADI_MP3_DEC_NEED_MORE_DATA.

output_status.num_input_bytes_consumed is always equal to the size of the input buffer - 1MByte and 128kBytes respectivelly.

output_status.dec_read_ptr is always set to the beginning of the input buffer, no matter if the first frame is located at some offset frame, already determined by my function.

There is also no output at the first call to adi_mp3_decode.


After that decoding works as expected.


At some points, depending on bitrate after calling adi_mp3_decode, returned result is ADI_MP3_DEC_NEED_MORE_DATA and output_status.num_input_bytes_consumed is once again equal to the size of the input buffer.

The value of output_status.dec_read_ptr remains unchanged.

At 320kbps this may happen about 9 hours later, at 128kbps this happens every 3-4 minutes.

I've managed to work arround this issue by checking if the value of output_status.num_input_bytes_consumed is bigger than the value of available bytes in the input buffer and ignoring it.


But more strangely after aprox. 15 hours and 30 minutes the decoder becomes insane.

In one of the cases the input buffer has 82016 bytes. Calling adi_mp3_decode first consumes 6724 leaving 75292 bytes in buffer. Next call consumes 74880 bytes leaving just 74880 in the buffer. Several seconds of data are gone in just two calls !!!

And that happens on many devices after exactly 15 hours and 30 minutes, plus/minus 1 minute.

It happens with different data sources - Winamp/Shoutcast, proprietary server using ADI MP3 Encoder library and LAME encoded MP3 files. There is no Meta or ID3 in the MP3 data, only MP3 frames.


Please help me resolve this issue ASAP.