I'm afraid I have no idea on this one, we'll have to wait for rogueb to turn up.

The issue I think will be is that the data has to get from the internet, interpreted with the ethernet shield, through the arduino, into the rMP3, onto the SD card then back off the SD card to play it.Not sure how much of that is possible/if there's some way to get round it and make it work.

Well, talking to rogueb, sounds like the board could probably do it but the arduino might still be the limiting factor, wouldn't be easy anyhow.The issue is getting the data to the board from the internet.

Yes, I think so. I am not sure if the stream needs to be decompressed before being written into the buffer.The idea I had initially was to use two or three buffers, to fill one in with the incoming data while the other is being played.

There is a similar project you could source some code from at http://www.circuitcellar.com/avr2004/HA3814.html

Interesting. I do wonder how the mp3 chip is talking to the microcontroller there.[edit]The schematics are linked from that page. External SRAM presumably for buffering (perhaps not though) so an rMP3 with some SRAM and an XPORT and a few code mods should do what you're after.[/edit]

The rMP3 has its own onboard ATmega644 so by itself it is probably capable of performing the functions you require but that would require re-programming the on-board chip and connecting eithernet shield directly to it.

oops, I didn't see that all the code was available in the 'Entry' link...Well, never mind, the author confirmed that the code is GPL v3 so I can have a look, even though it was using a totally different hardware.Anyway, I'll see that for now.

OK, so I had a look at the code from the 2004 project. If I underestand correctly, the microcontroler redirects the data to the buffer and uses a 'streaming mode' from the MP3 decoder so that there is no need to manage the flux.Taken that way, it may not be that difficult to realise. Do you know if the rMP3 has a streaming mode that can be used for the same purpose?

I've been toying around with a direct streaming mode for the rMP3. The decoder can do it.

I just need some time to code it. Unfortunately, I've been pretty busy with Wiring and new products lately and I won't get a chance until late January before I can even look at the rMP3 firmware for new updates.

The idea of buffering the data to a file is possible... in theory. You couldn't have an endless stream, though - that will only work with the direct stream mode.

The ONLY way it would work is:

you know the length of the data (essentially a file)

you download the data FASTER than it can play (so if you can only get data/store data at 115200bps, your MP3 stream/file can not be faster than that - I would keep it at 96kbps)

I see another possibility though: if i use three different files to buffer the data, it should be possible to play the stream:1) fill in the 1st buffer, then the 2nd buffer with the stream2) play the 1st buffer while filling the 3rd buffer3) play the 2nd buffer while filling the 1st bufferetc...

If the rMP3 can play two files consecutively without delay, we shouldn't hear the transitions between the buffers?

So far I have been able to copy a file from my computer to the SD card by serial port. I'll try to do it via the network now...