Go Down

Topic: * MP3 Shield * - Rogue Robotics rMP3 (Read 48681 times) previous topic - next topic


Hmm that is an interesting idea.

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.



One more thing: I am using the ENC28J60 ethernet shield (v1.1), it uses a different library than the others.


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.


why would the rMP3 have to write to the SD card while playing?.
Is it for buffering?.

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

PS: you refer to an SSD card when it should be an SD card.


Dec 14, 2010, 11:21 am Last Edit: Dec 14, 2010, 11:29 am by mowcius Reason: 1
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.


Thanks Mowcius, that looks like I want to do, but I cannot see an rMP3 module. It probably uses a custom-made script... Anyway, I'll contact the guy, see what he is willing to give.


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.


Well, "totally different hardware" in the sense that it is not an Arduino.

But, his design still uses an AVR microcontroller.  His code is more extensive than one would expect in an Arduino (where higher level libraries are provided).

It's an interesting project you've undertaken LB01.


It's an interesting project you've undertaken LB01.

Well I suppose 'interesting' is one way to put it  ;)


"headache-prone" is another way to say it. :)

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?


Do you know if the rMP3 has a streaming mode that can be used for the same purpose?

Heh, I think the chip might. No idea about how to do it on the rMP3 board.

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)

If at any point the decoder ran out of data, playback would stop.

I haven't tried it, but it should work.


Check out the Rogue LEDHead.

Wiring - Where it all began.


Dec 16, 2010, 06:11 pm Last Edit: Dec 16, 2010, 06:17 pm by LBArduino Reason: 1
Thanks for the ideas, bhagman!

Ok, no streaming at the moment so I have to do with buffering.

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 stream
2) play the 1st buffer while filling the 3rd buffer
3) play the 2nd buffer while filling the 1st buffer

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...

Dec 16, 2010, 10:19 pm Last Edit: Dec 16, 2010, 10:42 pm by bhagman Reason: 1
Unfortunately, in the current firmware, there will be a small delay.  (10s of milliseconds, but it will be noticeable to the human ear).

You just gave me an idea that I'd like to try out as well.  It only took me a few minutes to make the change in the firmware.

The new firmware has a setting which when set will not reset the decoder.  This will remove the delay between files.

I just tested it, and it works great.  So your concept with 2 or three file buffers will work.  (Gory detail - you won't even have to break the file at MP3 frame boundaries)

I'll have to make some changes to the RogueMP3 library to utilize the Play Next command (PC N).  This will automatically play a file right after the current one finishes.

Download: rMP3-100-02-b003 firmware

Rogue Robotics rMP3 Playback Module

Wiring - Where it all began

Go Up