* MP3 Shield * - Rogue Robotics rMP3

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.

Mowcius

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.

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

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 :wink:

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

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.

b

--
Check out the Rogue LEDHead.

Wiring - Where it all began.

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

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

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

b

Rogue Robotics rMP3 Playback Module

Wiring - Where it all began

That is great! Thanks a lot bhagman!
So I need to upgrade the firmware before I do anything now. I will try something either tonight or tomorrow morning. Cross fingers! :wink:

Ok, so here is a recap of what I've done this morning:

  • upgraded firmware via arduino (btw, the java updater doens't find any COM port, I had to use the command line method)
  • installed arduino 21, then installed the arduino stream pack (18/10/10), rogue MP3 pack (v3), rogue SD pack (v4), NewSoftSerial pack (18/10/10) and ethershield pack (v1.1)
  • Tested the ethernet board: I needed to rename the files from 'etherShield' to EtherShield', but then I could access the web page from my house network :slight_smile: moment of happiness
  • Then I placed a file on the root folder of the rMP3 SD card with the characters 'D3' and carriage return to set the rMP3 module baudrate to 57600 bauds
  • I uploaded a script and it works fine! :slight_smile: (Well, I had to work a bit)
  • Then I tried to upload a song from the serial port using the following script and it caused problem: the quality of the music is degraded during uploading (there are small pauses of ~100ms every 100ms) and the file is not copied correctly. The function below is called when the user send 'w' on the USB port:

void writeFile()
{
int8_t filehandle;
uint8_t v = 8;

Serial.println("Enter the name of the file:");
Serial.read(); // flush the data

while(!Serial.available()) // wait for data to arrive
{
Serial.print(".");
delay(500);
}
int length = 0;
name[length] = Serial.read();
while (1)
{
delay(10); // wait for the next character
if (Serial.available())
{
length++;
name[length] = Serial.read();
}
else
{
break;
}
}
// at that point we have the name of the file to write, so we can open a file
filehandle = filecommands.open(strcat("/", name),open_mode(OPEN_WRITE));
if (filehandle<1) // in case of an error during the opening
{
Serial.println("Error: cannot open the file.");
return;
}
// next ask for the data to write in it
Serial.println("Load the data:");
while(!Serial.available()) // wait for data to arrive
{
delay(10);
}
Serial.println("");
Serial.println("Loading...");
int i = 0;
while (1)
{
i++;
if (Serial.available())
{
char buf = Serial.read();
filecommands.write(filehandle,1,&buf);// write the buffer
//Serial.print(buf);
i = 0;
}
if (i>10000)
{
break; // ends on timeout (maybe 10000 is a bit large)
}
}
// finally, close the file
filecommands.close(filehandle);

updateSongList();
Serial.println("Done!");
}

It is probably not the best way to copy a file of th SD card. Is there any obvious mistake or suggestions?

I have another problem now: the rMP3 won't synchronise. It stops when I use the sync method.

Its getting somewhere:
I am using the ethershield library from nuelectronics, and I can now download data from a server. I have tried with google.com, and it (sort of) works :slight_smile:
About the rmp3, I can sync again (it was a problem with the compiler) but the SD card has been damaged beyond repair the last time I tried to use the module. I am not sure if that is due to a bug in the new version of the firmware, if it comes from the sync problems or if the card is just dead from old age...
Anyway, I wont have time for it before a few days. Merry christmas to you all!

Hey LB01,

Same with me... Holidays are here. I'll help out more in the new year!

Enjoy, be safe, and happy holidays!

b

Hi and happy 2011 to all ! :smiley:

I just tested my newly arrived rMP3 on an Arduino Mega 2560 with the arduino 0022 IDE.
I rerouted the rMP3 #6 and #7 pins to the mega's #19 and #18 (serial1), as per rMP3 On An Arduino Mega - Rogue Robotics
(in fact I rerouted from the pin pads in order to be able to stack shieds above the rMP3).

Then I installed the rMP3 library, and tested the example given in the above-linked page, and it worked immediately ! GREAT !!! :sunglasses:

I'm surprised because I thought I would have to do the "Core-stream-baseclass thing" ( http://www.roguerobotics.com/wikidocs/code/arduino_serial_base_class ) to make it work, but it seems that on the Arduino Mega, it's unneeded. Am I right ? I have the feeling it is because with the Mega's Serial1, the Softwareserial lib is not used, whereas it was on smaller boards ?

Is it so simple ? should I still do the Stream Class update for any reason, e.g. more-advanced use of the rMP3 features in the future ?