Ethernet MP3 Player

Have you tried setting the baud rate with the boot config file on the SD card instead of in code?

Yes, I did that first and I could not sync either when I used D5 and D7 as parameters.
Using D0 was not a problem, but 9600 is too low for streaming.

Since you're using the Duemilanove, you won't be able to get much better than 57600 bps on a SoftwareSerial port. Can you try setting the rMP3 to 38400 bps? (Setting: "D2")

See if that works. If it does, you'll have to:

  1. use Serial for your communications with the rMP3 (you will have to add jumpers from pins 6 and 7 to pins 0 and 1 - and you will have to remove the rMP3 each time you upload a sketch).

  2. use another board which has an extra hardware serial port (e.g. LEDHead, Arduino Mega, etc...

Oh I had forgotten about the Software Serial speed limitations - glad you came to the rescue with answers :smiley:

ok, so 38400 works for the sync but the stream is corrupted. I suppose the write operation to the SD takes too long at that baudrate.
So I will try to do as bhagman says. I will see if I can go up to 57600 using the serial port. Will I still need the SerialSoftware library?

If you use the hardware serial port, you won't need SoftwareSerial any more.

Just remember that you will have to remove the rMP3 (with power removed) each time you want to upload! (This only applies when using the same hardware serial port that is used for uploading the sketch).

e.g.

#include "RogueMP3.h"

RogueMP3 rmp3(Serial);

void setup(void)
{
  Serial.begin(57600);
  rmp3.sync();

  ...
}

I had some spare time to work on that issue.

I soldered a couple of pins to make it easier to connect/disconnect the rMP3. It works well, the only things is that it is confusing that the Tx/Rx pins on the solderable pads must be connected to the Rx/Tx of the arduino serial pins respectively (it must be a crossed cable). Apart from this point, I like this system, it is very flexible.

So I connected everything and modified a simple script to play a tune with the rMP3 using the serial port, and it works very well at 9600 but still fails at 57600. Basically, when I change the option D0 to D3 with the correct serial baudrate, the music does not start. Here is the setup function:

void setup()
{
  delay(2000);
  Serial.begin(9600);  // initialise the serial rMP3 connection
  
  rmp3.print("ST D0"); // if changed to D3, the module fails
  delay(100);
  Serial.begin(9600); // that would be changed to 57600
  delay(100);
  
  rmp3.sync();
  rmp3.stop();
  rmp3.setvolume(volume);
  
  filecommands.sync();

  // mix up our random number generator
  randomSeed(analogRead(0));

  updateSongList();
  
}

I suspect that the sync is still a problem. Any suggestion?

  Serial.begin(9600);  // initialise the serial rMP3 connection

rmp3.print("ST D0"); // if changed to D3, the module fails
  delay(100);
  Serial.begin(9600); // that would be changed to 57600
  delay(100);

You have two 'Serial.begin(####)' lines in there...

yes, I use that to set the baudrate to whatever I need. It is not nice, but with that I don't need to change the config file on the SD card everytime I change the baudrate. And it works when I use 9600. It also works when I set 57600 and then come back to 9600.

The only thing I can see is that you don't send the <CR> to complete the command.

Try this:

  rmp3.print("ST D3\r");

Thanks a lot, it is now working! I did forget the \r to validate the changes, it seems like my shortcut to change the baudrate created more problems than it solved.

Anyway, I can now see the LEDS flashing on the ethernet shield, so the stream is coming. I can also see the indicator lit on the rMP3 and some data is written on the SD card but it cannot be read when the card is connected to my computer. The data is corrupted somewhere.

I suppose that the write operation is still too long for some reason (the 'Data in' LED of the ethershield board does not flash very often). At the moment, I am using a byte-by-byte write operation because the stream buffer is a uint8_t and the write methods needs a char. Here is what I was doing:

char s;
  while (pos<plen) // write the remaining data to the buffer
  {
    s = char(buf[pos]);
    filecommands.write(filehandle,1,&s);
    pos++;
  }

I replaced it by the following:

char s[plen];
  while (pos<plen) // write the remaining data to the buffer
  {
    s[pos] = char(buf[pos]);
    pos++;
    sdpos++;
  }
  filecommands.write(filehandle,plen,s);

but now a red LED starts to flash on the rMP3 when the stream arrives. I suppose that means a buffer overflow because i pass on too much data in one go?

Still no luck, I have this red LED flashing on the rMP3 board whatever I try to do. What does this LED means? I can at best write 40 - 60 characters on to the SD card before it starts to flash.

Hi LB01,

I've been quietly watching your project since it began. It would be such a cool project for the Arduino and the rMP3!.

There's a writeup of a related project DIY MP3/OGG/FLAC music player using Arduino and VS1053 at http://kalum.posterous.com/private/sHqcofxooc that could be worth looking at. It's not strictly playing streaming radio, but the code could give you some ideas.

Hi Novice,

Thanks for your enthousiasm, to be honest I left this project aside because I could not get any progress.

Using the arduino duemilanove, the rMP3 and an ethreshield, I managed to capture an icecast stream correctly but it could not copy it to the SD card (on the rMP3 board). If I redirect the stream to the USB serial port, it does work! I can listen to the radio, no problem. But as I said, the problem I have now is to copy this stream to the SD card on the fly and there is a problem with the rMP3 card with that, the write function fails 90% of the time to copy the data. Apart from that, the rMP3 module seems to work fine so I feel like I am close to completion...

Ok, I will try and make it work again, but that will probably need some changes in the rMP3 firmware too.

Hey LB01,

I've been thinking this over, and I don't think that using the files will be the best way to go. I've got a new idea (not really rocket science) to just add a direct serial stream to the decoder. Should be pretty easy to do. I'll update you when I get the coding done.

b

oh great ! I'll be waiting for it!

I just replied to your first email and I sent you the code that I wrote so far, but you may not need to look at it if you develop your idea. At the moment I can get a 128k/s icecast stream without a problem using a baudrate of 230400, but only if I redirect it to the USB port. Copying to the rMP3 SD card fails. If you can manage to make a direct protocol, then I think it will be very straightforward for me to finish.

I'm working on a project, that includes the tranferring of audio via ethernet and playback by Arduino.
Therefore I watch the thread with great interest and I hope that you guys might get it working.

LB01:
oh great ! I'll be waiting for it!

I just replied to your first email and I sent you the code that I wrote so far, but you may not need to look at it if you develop your idea. At the moment I can get a 128k/s icecast stream without a problem using a baudrate of 230400, but only if I redirect it to the USB port. Copying to the rMP3 SD card fails. If you can manage to make a direct protocol, then I think it will be very straightforward for me to finish.

The main issue with a ethernet streaming mp3 player is the buffering of data packets. The AVR has only 2k of RAM which is not enough to buffer the TCP/IP packets form the ethernet controlller, buffering is needed as packets form the internet can be corrupted etc, so the ideal setup would be the avr connected to the ethernet controller and additional ram available via a SPI interface. The SPI interface can also be shared with the vs1053 mp3 decoder chip to complete the ethernet based mp3 streaming media player. This kind of setup is seen on the vs1053 page for the PIC family and ARM.

http://www.watterott.net/projects/webradio-arm

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en536047

The key issue is the code to interface the external SRAM to buffer the ethernet packets. If that can be sorted out, you will have your avr based streaming mp3 player :slight_smile:

kalum:
The main issue with a ethernet streaming mp3 player is the buffering of data packets. The AVR has only 2k of RAM which is not enough to buffer the TCP/IP packets form the ethernet controlller.

The VS1053 has a 2K internal memory dedicated to buffering incoming data. I wonder if that would be enough of a buffer, so I'm going to try this out. At 160kbps, that buffer holds 100ms of audio, so you've got that long to fill it up with data over the network. In theory, that should be plenty of time. It will be interesting to try!