EmbDev.net

Forum: ARM programming with GCC/GNU tools AAC/MP3 Player Helix: How much RAM?


von Michael (Guest)


Rate this post
useful
not useful
Hi,

how much RAM is needed minimal for decoding MP3 in software with the
Helix decoder?

On the Helix project webpage ~24kB RAM are specified. But here
(http://www.koders.com/c/fid806E0B3351656049B5BDEED8EC5AB01ADD2CE28B.aspx)
it seems somebody has implemented it on an AT91SAM7S64, which has only
16kB RAM.

Thanks in advance.
Michael

von Andreas S. (andreas) (Admin)


Rate this post
useful
not useful
Hi,

realistically you need >> 30 kB. I'm not using an AT91SAM7S64 but a
S256, the name of the linker script is wrong.

Andreas

von Michael (Guest)


Rate this post
useful
not useful
Hi Andreas,

first i want to say thank you for your answer.

My problem is, i've to port the MP3 player to an ARM7 of TI. It has more
than enough flash memory (256kB) but only 16kB RAM (it's the
TMS470R1VF4B8). So is there any realitical way to go? I'm thinking about
deleting MP3 status data (i.e. ID3 tag) which i don't realy need,
supporting not the whole standard (maybe no support for AAC files) and
so on.

I think you know lot about this codec, so my queston for you is: Is
there any realistical way for me to go?

Best regards,
Michael



Andreas Schwarz wrote:
> Hi,
>
> realistically you need >> 30 kB. I'm not using an AT91SAM7S64 but a
> S256, the name of the linker script is wrong.
>
> Andreas

von Andreas S. (andreas) (Admin)


Rate this post
useful
not useful
No, it's definetely not possible. Take a look at buffer.c to see how
much is allocated to what.

Andreas

von Christian G. (Guest)


Rate this post
useful
not useful
I managed to get the decoder running quite happily on a LPC2138.

This MCU has fast flash memory, so you don't need to run code from RAM
(at 60MHz, it decoded a 320kb/s frame in an average of 17ms). By
replacing malloc() with static assignments (saves ~2k), reducing the
input buffer to the size of a single frame (1056 bytes for a 320kb
frame) and synchronizing the decoder output to the DAC-ISR (saves
another 4,5kB), the decoder finally needed about 28k RAM including all
buffers, leaving the rest for stack and heap of the main application.
I also tweaked the MAINBUF_SIZE in mp3dec.h a bit, which might save you
a few hundred bytes, depending on your maximum bitrate.

Realistically, you might consider using a chip with at least 32kB RAM.

Regards,

Christian.

von Ron A. (ronanejo)


Rate this post
useful
not useful
Christian G. wrote:
> I managed to get the decoder running quite happily on a LPC2138.
>
> This MCU has fast flash memory, so you don't need to run code from RAM
> (at 60MHz, it decoded a 320kb/s frame in an average of 17ms). By
> replacing malloc() with static assignments (saves ~2k), reducing the
> input buffer to the size of a single frame (1056 bytes for a 320kb
> frame) and synchronizing the decoder output to the DAC-ISR (saves
> another 4,5kB), the decoder finally needed about 28k RAM including all
> buffers, leaving the rest for stack and heap of the main application.
> I also tweaked the MAINBUF_SIZE in mp3dec.h a bit, which might save you
> a few hundred bytes, depending on your maximum bitrate.
>
> Realistically, you might consider using a chip with at least 32kB RAM.
>
> Regards,
>
> Christian.

Hello,
I'm working on the similar kind of project too. But currently I'm not
able to implement it on real time (I use MMC to store the output then
play it later as a WAV file), so I wonder if you would mind to answer my
question here (or maybe even let me to take a look at your project :) ).

1. Can you tell me about how to calculate the MAINBUF_SIZE based on bit
rate?

2. Currently, my concept of decoding on real time is to decode a frame,
and then copy some of the PCM output on a buffer (size is depending on
how much time used for a decoding process) then decode the next frame
while the next frame is decoded. Is that right? So, can you tell me more
about "synchronizing the decoder output to the DAC-ISR" that save
another 4.5 kB (hmm... yummy :)).

3. Do you know how to implement the note on coder.h just before the
declaration of _SubbandInfo about "using the less RAM for if the RAM is
more valuable than speed"? It says something about using memmove instead
of DCT32 on subband, but I wonder how.

4. I'm using an I2S DAC (CS4334), currently only supporting 44.1 kHz
sample rate, do you have any idea for my system so it can support MP3
with other sample rates? (Helix decoder options)

Thank you very much, this article gives me some hope to complete my
project on real time system.

Best regard,

Ron

von Ron A. (ronanejo)


Rate this post
useful
not useful
Ron Anejo wrote:
> 2. Currently, my concept of decoding on real time is to decode a frame,
> and then copy some of the PCM output on a buffer (size is depending on
> how much time used for a decoding process) then decode the next frame
> while the next frame is decoded. Is that right? So, can you tell me more
> about "synchronizing the decoder output to the DAC-ISR" that save
> another 4.5 kB (hmm... yummy :)).


Sorry, I mean:
 2. Currently, my concept of decoding on real time is to decode a frame,
 and then copy some of the PCM output on a buffer (size is depending on
 how much time used for a decoding process) then decode the next frame
 while the current frame is played. Is that right? So, can you tell me
more
 about "synchronizing the decoder output to the DAC-ISR" that save
 another 4.5 kB (hmm... yummy :)).

regard,

Ron

von Thiadmer R. (thiadmer)


Rate this post
useful
not useful
Ron Anejo wrote:
> [...] So, can you tell me more about "synchronizing the decoder output to
> the DAC-ISR" that save another 4.5 kB (hmm... yummy :)).

I think what Christian means is that he has modified the Helix source
code to send each decoded sample immediately to the DAC, instead of
storing it in the output buffer. The output buffer is MAX_NGRAN *
MAX_NCHAN  MAX_NSAMP  sizeof(short) in size, which computes to 2  2 
576 * 2 = 4608 bytes.

I think that you will need some kind of output buffer. Making the MP3
decoder output each sample at exactly the right time will become painful
if you also have other work for the microcontroller (e.g. a user
interface).

It may be not too difficult to halve the size of the output buffer (from
4.5 kiB to 2.25 kiB). The Helix code processes the data per granule (576
samples), but it loops over two granules before returning. You could
modify the Helix code to call a callback function once a granule is
done. That callback function then moves the data to the DAC.

Regards,
Thiadmer Riemersma

von Christian G. (Guest)


Rate this post
useful
not useful
Thiadmer Riemersma wrote:
> Ron Anejo wrote:
>> [...] So, can you tell me more about "synchronizing the decoder output to
>> the DAC-ISR" that save another 4.5 kB (hmm... yummy :)).
>

Just adding some final words to this now quite dated thread. Maybe there
is still some interest in it:

It's almost like Thiadmer's second suggestion:
The ISR for the DAC constantly loops over the decoders output buffer.
I modified the Helix code to check which half of the output buffer the
DAC pointer of the ISR is pointing to. If it is the same half the
decoder wants to write to, it just waits.
After writing both halfs of the buffer the decoder returns to the
calling process.
With this small modification you dont't need a dedicated double buffer
and don't waste any processor cycles for copying data.

Best regards,

Christian.

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.