[Michael P. Flaga]

Sounds fun. I suggest looking at “arduradio” it was based off an older version of this library. I was real close to that with the WebPlayer.ino after seeing the Arduradio, just not enough time. But it is definitely possible.

I would be interested in reviewing and possibly merging the Due.

Best way to contribute is to create a GITHUB account, then fork the library. And commit your changes. Then let us know. We can then review and merge applicable components of the forks.

[Michael P. Flaga]

Glad to hear.

Have Fun.

[Michael P. Flaga]

Try FileNamePlayer.ino on my GISTHUB

It should be just what you are looking for.

Although take note that the Arduino IDE Serial Monitor sends out a few bytes of garbage, that may cause a little of confusion.

This sketch listens for commands from a serial terminal which are TERMINATED with New Line Feeds (aka “\n” or 0xA). To use this sketch enable Serial Monitor to use NewLine’s.
If the Serial message is 1 byte in length and terminated by LF, the byte will be processed as menu command.
If the Serial Message is larger than 1 byte it will assumed a FileName and that file will be attempted to be played. Note the max length of string is 8.3 or 11 bytes long.

So with this you can send the actual filename exactly as seen in the listing.

Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V,l,01-65534 :
[MPF: I sent “TRACK001.mp3” + LF using Serial Monitor]
Received > “TRACK001.mp3”
Playing = TRACK001.mp3

You can still send commands such as “s” to stop but they too need to be “s”+<LF>

[Michael P. Flaga]

The code is an example, meant to demonstrate features and was purposed to be as flexible as possible. Where my implementation wanted to be able to play and infinite list other files, beyond that of track0000.mp3. Hence the play and list feature simply sequence through the openNext of the SdCard, displaying all playable files with matching *.ext.

fileplayer.ino Line 372:

while (file.openNext(sd.vwd(),O_READ))
{
file.getFilename(filename);
if ( isFnMusic(filename) ) {
SerialPrintPaddedNumber(count, 5 );
Serial.print(F(“: “));
Serial.println(filename);
count++;
}
file.close();
}

I would expect the list and its corresponding enumerations should be consistent, as the openNext(), is sequencing through the SdCard’s FAT entries. Which should not change, unless you add files to it. Which won’t be something you do often, or on the fly at least. So I suspect you can manually list out the playable files with the “l” command and go with that list, until you change things. At which time you could check it again.

That all said. There is nothing preventing you from changing the code (it is an example) to fit your own needs. where you can change the below section to your needs.

fileplayer.ino Line 173:
…
while (file.openNext(sd.vwd(),O_READ))
{
file.getFilename(filename);
if ( isFnMusic(filename) ) {

if (count == fn_index) {
Serial.print(F(“Index “));
SerialPrintPaddedNumber(count, 5 );
Serial.print(F(“: “));
Serial.println(filename);
Serial.print(F(“Playing filename: “));
Serial.println(filename);
int8_t result = MP3player.playMP3(filename);
…

I recall your original problem is that you wanted to play a specific track, but not limited to 0-9 tracks. and were having problems with multi digit characters being sent and received. You can remove the above while (file.openNex… file.GetFilename and if( isFnMusic… and replace filename with a construction of your choice, similar to what happens at lines.

The fileplayer.ino can help that. Where it was developed for a more general application. The features of ICT or delimiting can be re-used, by stream lining/hacking to better fit your needs.

Ahh, screw it. I just made it and posted it here on GISTHUB  trackplayer-ino

This should do what you want. Simply send in 1, 01, 001, 0001 or o0001 to play TRACK001.MP3. Same for 02 to play TRACK002.MP3 and so on. Where you need to make sure your sender has at least 500ms pause between numbers or commands.

Diff TrackPlayer.ino and FilePlayer.ino to see the differences as mentioned above.

If you don’t want the 500ms then, you can change the code to remove the ICT and use something like CR/LF as the delimit to queue parsing.

[Michael P. Flaga]

With the fileplayer.ino as is, one does not send “f track002.mp3”. Rather one sends a multi-digit enumeration of the filename as discovered by the List “l” command and the Inter-Character Timeout will delimit the command.

Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V,l,01-65534 :
[MPF, I sent “l” to List out directory]
Received command: l
Music Files found :
00001: DING.wav
00002: TRACK001.mp3
00003: TRACK002.mp3
Enter Index of File to play
Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V,l,01-65534 :
[MPF, I sent “003”, to play #3 file from above]
Index 00003: TRACK002.mp3
Playing filename: TRACK002.mp3
by:
Album:
[MPF, I sent “s” to stop it]
Received command: s
Stopping
Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V,l,01-65534 :
[MPF, I sent 002 to play #2]
Index 00002: TRACK001.mp3
Playing filename: TRACK001.mp3
by:
Album:
[MPF, I sent 001 to play file #1]
Index 00001: DING.wav
Playing filename: DING.wav

“f” will just simply play track001.mp3.

 

[Michael P. Flaga]

So you must not be using the Arduino’s built in Serial Monitor, as from the sounds of it. Where the IDE’s Serial Monitor does not send each character one at a time, but rather as a whole line.

The original MP3Shield_Library_Demo.ino only accepts one character at a time and processes each character as individual commands when more than one is sent at once.

FilePlayer.ino is different in that for numeric digits it delimits it serial input by Intercharacter Timeout, which is 500 ms as in the below line. Grouping the individual digits into a whole integer.

  } else if ((millis() – last_ms_char) > 500 && ( buffer_pos > 0 )) {

So you are likely typing each character with more than 500ms between them. Causing the ICT to attempt to parse the serial buffer. You can increase the 500ms ICT. Or you can paste the whole command at once. More like the desired Serial.Print would.

Where as it does not ICT for non digits. Where it still processes them individually.

Looking at your trace it looks like you were typing: “track.mp3”. That is not the way FilePlayer.ino works.

Rather you should run the “l” command to

Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V,l,01-65534 :
Received command: l
Music Files found :
00001: DING.wav
00002: TRACK001.mp3
00003: TRACK002.mp3
Enter Index of File to play
Enter 1-9,f,F,s,d,+,-,i,>,<,p,r,R,t,m,M,g,k,h,O,o,D,S,V,l,01-65534 :

Where you would enter 00003 to play “TRACK002.mp3”. You don’t type in “TRACK002.mp3”.

So if you are sending “TRACK.MP3” I believe it is likely parsing each character as a unique command.

Note also that “f” is a command to play “track001.mp3”.

[Michael P. Flaga]

There was a minor typo in the above example. Where “n” is the track number you are calling.

for (int n = 0; n < 9 ; n++)
{
MP3player.playTrack(n);
while (MP3player.isPlaying());
}

And since it is called by the loop the loop “n” knows which track is playing.

More advanced one could rely on the SdFat Library to know which filename is playing.  The below code is the key components for it

SdFile file;
char filename[13];
file.getFilename(filename);

But it has been awhile since I have used them. So it would take some trails to get it going. But likely not too difficult.

[Michael P. Flaga]

Yes, you could you cut SJ2 or remove D13 from the SFE MP3 shield, freeing D3, from the VDSP’s UART’s RX pin. Where this signal is safely pulled up, as to make it idle. Note that in the code D3 is not actually implemented. So again it is available, for you to use. I believe I have done this before for PWM to drive IR LED’s.

You want to cut the VDSP’s UART RX pin is principally for MIDI commands but it also can be used for other items. Hence it is wise to severe the PWM’s output to this, as not to cause superfluous UART data to the VDSP.

Similiarly D4 can be recovered, by cutting SJ1 or removing R14, to get another Digital IO

[Michael P. Flaga]

Not sure if you question was answered with the other post.

Whereas if you are going to simply play a sequence of tracks. The quick start is a good place along with the use of MP3player.isPlaying() function as to tell when a track is finished. Where something like the below would be a quick attempt to play track000.mp3 through track009.mp3

for (int n = 0; n < 9 ; n++)
{
MP3player.playTrack(key_command);
while (MP3player.isPlaying());
}

 

[Michael P. Flaga]

Both MP3Shield_Library_Demo.ino and FilePlayer.ino work out of the box, straight from the download. Where FilePlayer.ino is nearly identical to the original MP3Shield_Library_Demo.ino, except with a more serial flexibility, that may help your desired goal.

Are you indicating that MP3Shield_Library_Demo.ino works but FilePlayer.ino? doubt it. As above they work out of the box and with identical under structures.

Your description of the symptoms are consistent with a DREQ interrupt problem. Please refer to the Troubleshooting . Specifically the subsection labeled “Why do I only hear 1 second of music, or less?” (sound familiar)

You can verify a DREQ interrupt problem by not using interrupts. Change the SFEMP3ShieldConfig.h line 195 to

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

rather than USE_MP3_INTx.

[Michael P. Flaga]

Your pasted code has an error with buffer[received] = “; but that is likely do the the pasting and not actually in your code. Your issue is about the difference in real time versus slow input. Not sure what the problem is, looks reasonable. but being a realtime problem it needs extensive debugging. I do notice that you may want to employ a delimit, such as a carriage return. i.e. 123<cr>, as to denote the ending and flag for processing the received string. This helps with lining up the messages. There are plenty of discussions out there on adding common delimits and framing. Which is the problem here.

Where as you can check out the example FilePlayer.ino. Which I created to allow larger serial messages or filenames. Per its notes.

* This sketch behaves nearly identical to MP3Shield_Library_Demo.ino, but has

* extra complicated loop() as to receive string of characters to create the

* file index. As the Serial Monitor is typically default with no CR or LF, this

* sketch uses inter character time out as to determine when a full string has

* has been entered to be processed.

This is basically what you are asking for, where as it is a bit more flexible and so being more sophisticated and complex. It uses Inter character Timeout as to delimit the requested bytes into a Frame. Or file name in this case. Allowing you to send the whole file name. Getting you longer list of files (infinite) you are able to play.

 

 

[Michael P. Flaga]

Basically same thing as SVN. Nice thing about the GIT HUB’s forking and cloning from GitHub, is it is just too darn easy with the buttons/links on the web page.

GitHub has a quaint GUI. but it hides a lot.  I recommend TortoiseGIT. If you don’t like command lines. (i don’t).

I clone all to a local repository directory and then create symbolic links to the ..\arduino\library\.. directory for each actual libraries directory. For windows you can use the little known “junction” command to make “hard-links” (same thing).

Basic steps;

1. fork a repo from someone else on GitHub. This is basically cloning from their cloud to your space on their cloud.
2. clone your repo locally.
3. change it.
4. commit changes.
5. push changes, back to original/remote repo.
6. Then from the GitHub page make a pull request back to the original fork. This is basically making and sending a Serial patch, back up to be merged back in.

[Michael P. Flaga]

Sounds exciting

Best way to contribute is to create a GITHUB account, then fork the library. And commit you changes. Then let us know. We can then review and merge applicable components of the forks.

The wonders of community version control.

[Michael P. Flaga]

Error Code 4 indicates that the library did not get back the expected value back from the VS1053 chip, while trying to initialize it just after reset or boot. Where you are able to read the SdCard.

After commenting out the above mentioned line; Did it play successfully?

Note: SM_LINE1 & SM_SDINEW are DEFINE’s of bit masks of the SM_MODE register. On these bit positions on the VS1053 should be the only values set true in the SM_MODE register after reset. Your prints showing 0x0 is indicating you are likely not talking to the Chip.

I am not familiar with the Seeeduino (Duemilanove clone). I would expect it to be equal to the Duemilanove not requiring anything special. Check you solder connections of the headers and perhaps ohm out the connections from chip to chip. And check that the pins are working as expected all they from the Duemilanove to the VS1053.

I also see the  Seeeduino (Duemilanove clone) has a 3V vs 5V switch. Ensure it is 5V, if you have not modified the SFEMP3Shield for 3V operations, as noted in the GitHub Page. If this is the problem, let me know I will update the Troubleshooting Guide to additionally include this about the Seeeduino (Duemilanove clone). Although I doubt this the problem.

[Michael P. Flaga]

About the your CPU % observation. It is significantly dependent upon the bit rate of the audio file. A 192K will take a lot more than a 44K. Additionally you can significantly increase efficiency by setting:

#define USE_MP3_REFILL_MEANS USE_MP3_Timer1

or

#define USE_MP3_REFILL_MEANS USE_MP3_SimpleTimer

along with setting MP3_REFILL_PERIOD to an appropriate period to accommodate the bitrate of the audio file.

This will more efficiently bundle the Reads from the SdCard and subsequent writes to the VS1053 into larger chunks. Noting that the SdFat Library pre-reads a cache of 500 bytes and the MP3 library writes little chunks of 32 bytes at a time, until the DREQ is full. Where I have seen a logic analyzer traces of it showing a lot of chunking that is removed when down more as a periodic refill. Better matching the SdFat’s 500 byte read.

[Author]

Posts