Hi,

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

Andreas

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

Andreas

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

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

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