Playing MP3's just stop and can hang Arduino

[Anonymous]

Hi

I hope someone can help.

I am using Bill Porters libraries to drive the VS1053 device (sorry not the Sparkfun breakout board but very similar).

I have had great success with the library and have managed to code all of the functions I need for my MP3 player. Thanks Bill for the work on this library, it has helped me so much.

The problem I am having is that after some indeterminate time of playing MP3 files the system will just stop and can also hang the Arduino Uno.

Setup
==============
Using USE_MP3_Timer1 for refill
Using sd.begin(10, SPI_FULL_SPEED)
Use MP3player.pauseDataStream() and MP3player.resumeDataStream() when interrogating VS1053 for track name or setting new volume level etc
Always use MP3player.stopTrack() and file.close() when switching tracks

Symptoms
==============
Stops at end of tracks or sometimes part way through MP3player.isPlaying() reports a 1. Changing track starts it again
Can hang the whole Arduino at end of track or sometimes part way through (happens less often)
Often hangs when trying to start a higher bit rate track. If it doesn’t hang then it is slow to start playing track.
Can hang Arduino at start of higher bit rate track but keeps playing file until end of that track
The stopping behaviour is not at a consistent point in the track list.

Tried
==============
#define MP3_REFILL_PERIOD 100 changing to 50 but no real change
USE_MP3_INTx does not seem to help

Playback is smooth but I suspect it is some interaction on the SPI bus for the card/VS1053. Despite checking forums etc, I have not found anything definite and I am struggling to know where to look next.

Hopefully someone can help.

Many thanks in advance

JasD

[Michael P. Flaga]

Its been a while. Whereas using the demo code I have been able to play track’s that are over 45 minutes long without issue.

My first guess; which is similar symptoms, is that the bit rate of the track is too fast. Where the ATmega is not able to keep up with reading the SdCard and then sending it to the VS1053.

Is indeterminate? a few seconds, minutes or 10’s of minutes?

[Anonymous]

Hi Michael

 

Many thanks for your quick response.

The time interval is probably in the order of 5 to 15 minutes.

The high bit rate file is 320kbs, when it does play this file it plays it fine, but often has trouble starting it.  The rest are 192kbs

 

When I start playing the file I have now added a pause before getting the file name to display.

 

MP3player.playMP3(filename, 0);

delay(500);

DisplayTrackName();

 

This does seem to help but I am not sure it solves it.

As a sticky plaster I detect when 3 consecutive track times are the same  (with a gap between each track time query) and then advance to the next track.  It works apart from the lockup case but it’s not really a good thing to do.

Any ideas?

 

Thanks

JasD

 

[Anonymous]

Just tried using <span style=”background-color: #fbfbfb; color: #5e5e5e; font-family: Arial; font-size: 12px;”>USE_MP3_INTx again and it appears to be working more reliably.</span>

I’ll do some soak testing and see if the problem arises again.

 

Fingers crossed

JasD

[Michael P. Flaga]

two items;

1. I am concerned that evey 192K bit rate may be too high. I have all my quite slower. I know I did limited testing and think I recall problems at 192K and over. Can you re-sample the file to a slower bit rate. I use SOX it is a command line that is easily made into a script.
2. Not sure if your DisplayTrackName is actually attempting to read the track file. If so the SdFatLib may have problems with bouncing back and forth positions in the current file.

I have no idea what your statement about the sticky plaster and lock up working is about.

[Anonymous]

Hi Michael

The VS 1053, Arduino Uno and library copes quite admirably at 192kbps and even 320kbps, stopping is only this problem that I have seen.  Using USE_MP3_INTx has helped but it still stops about every 10 minutes or so, but now there is much less processor hanging.

DisplayTrackName interrogates the VS1053 to get the MP3 title tag, so other than pausing the data stream for a short while, I think it is kind to SdFatLib.

My sticky plaster involves checking the ms track time using  MP3player.currentPosition() at 3  time intervals.  If the results are all the same then I know it has stopped and I advance to the next track.  It seems to work.

In-fact, the stopping tends to happen mainly at the end of tracks when moving on to the next.  I don’t know if this has something to do with flushing VS1053 buffers, perhaps too early or perhaps it forgets to ask for more data or the last file chunk?

Thanks for you help

JasD

 

 

[Michael P. Flaga]

The library has functionality when the file is ended or stopped it will flush the VS1053 buffers and update the state. There is manual flush function that can be called with options in the various ways of flushing before or after the STOP is issued.

Are you saying that occasionally the file will end but the state still indicates playing.

FYI.

Note that every byte has to be read from the SdCard and then written back to the VS1053, at 4M bits per sec. Hence 2M and then it needs overhead. So max is theoretically 200KB per second. but there is a lot of overhead.

Also the file public position pointer in the SdFatLib is only 16bit. So it works only as relative. Along with its cache buffer being only 500 Bytes. So if any other file access is attempted its dumped and re-read. and will likely cause a mess.

I believe I recall I changed the currentPosition to read the second position from the VS1053 rather than the file position, because of the prior limits and Variable Bit Rate can mess with it. The thing to note here is that the currentPosition is suspending and reading the VS1053 and resuming. Which works fine until real time become limited. Just FYI.

I believe I recall having such problems at these Bit Rates, and simply re-sample.

[Anonymous]

Hi Michael

Yes it does indeed seem that the file ends but the state indicates it is still playing.

I soak tested all last night with my sticky plaster workaround and it played all last night (no hangs) but had to force track advancement 50 times.  I would calculate that this is approximately 25% of the track advancements needing a bit of help.

It seems even with overhead that 2Mb/s is sufficient for the 320kb/s MP3 bit rate, but I do appreciate your concern at higher bit rates.  The only time I do any file access in the sketch is in-between songs when I am either selecting the next or previous track, I don’t make any file calls during playback but I do of course make calls to the VS1053 registers (I try to keep this to a minimum).

Based on what you’ve said, to I need to use MP3player.pauseDataStream() and MP3player.resumeDataStream() for the commands

currentPosition()

trackTitle()

setVolume()

or is this included in the macro?

Many thanks

JasD

 

 

 

[Author]

Posts