MP3player.currentPosition() incorrect?

[SanderM2]

While music is playing I'm printing MP3player.currentPosition() to my serial console. It seems that it never goes beyond 1 minute? I see values like this:

14:29:24.466 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 0 14:29:34.479 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 10240 14:29:44.533 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 20480 14:29:54.547 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 30720 14:30:04.588 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 40960 14:30:14.619 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 51200 14:30:24.636 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 61440 14:30:34.677 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 6144 14:30:44.687 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 16384 14:30:54.714 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 26624 14:31:04.758 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 36864 14:31:14.772 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 47104 14:31:24.818 -> Still playing: /Standaard/MUSIC/MUSIC011.mp3 @ 57344

As you can see, it seems to be clipping.

Is this a known issue?

[mpflaga]

I can say that from my memory; I was able to play files that were over an hour-long without any issue.

However, it has been a long time since I have looked at this library in any detail. I noticed the debug print is for 2 minutes. I not sure if it indicates that it is rolling over at 1 minute, when above the 60K value.

I assume this is from your code, as the Demo and Library does not actually print these. So, I would suspect that there may be a Type Casting problem with the Size of the file pointers.

My experience is that it is often something else messing with it.

Several other causes that come to mind could be. May be the SdFAT lib is now different. The Compiler version has changed An interrupt or another SPI device may be stomping on VS1053 SPI. Memory leak.

Often intermittent and un-explained events come from Power Glitch. Often these are from bad or floating grounds or inputs.

[SanderM2]

Hello,

It turned out my variable was of int type instead of a long. It’s fixed now :-)

But I do have a different issue. Sometimes, seemingly random, the music stutters for a couple of second, but I can’t reproduce the issue on request. It just happens randomly. It’s not a file issue either because playing the same file again usully works flawless…

I added logging to the refill() function that calculates the time it takes for track.read() to finish. When the music stutters i see that it takes 30-60ms while it takes about 2ms when music is playing fine.

I’m using an arduino mega. At first I thought the lose SPI wires could be the cause but I have soldered them in place and the issue hasn’t change. It’s still there…

So it looks like an issue with SD reading? Or maybe with the SD card itself? It’s a kingston extreme 32gb card. A new one. Should I buy another brand/size and test again? Or do you have any other thoughts on this?

Even with the main loop sketch is empty this happens so it can’t be an issue with my own code…

[mpflaga]

It is good to hear that you resolved the problem. And that it was related to my remote observation.

Have you ever seen it happen with the Demo Code?

Be mindful of prints. They are funny about how they use resources. 1) if not using F() they use a lot of RAM. 2) the transmit does use an interrupt for sending data. But only for the cores smaller buffer. They will block on larger messages. May be 16 or 32 bytes. Keep all prints very short when trouble shooting. That includes staying away from printf or sprintf, etc...

Something is blocking. The trick is to figure out where or what. Often for real-time things like this, you need to watch a bit (or LED) along with an oscilloscope or logic tracer. I wonder if the CS for the SdCard shows that it is getting stuck or stuttering there or if it is "In and Out". Watching the CS between the VS1053 and the SdCard, will tell you a lot about the real-time.

Any interrupt pins that are left floating will cause "weird" problems. You can also run the code without using interrupts for the refill. Just Polling , or as a Timer IRQ to refill the MP3.

When troubleshooting the SdCards, I would often just use the Examples in the SdFAT lib, to keep things simple. When this was first written the SdCards were not as big.

Lastly, you could try the AdaFruit VS1053. on the same SdCard. Note the AdaFruit VS1053, defaults to polled.