Skipping More than 65 Seconds

[Anonymous]

I have a VS1053b breakout board from ebay. It is generally working very well with this excellent library. However, I am struggling to find a way to jump playback by more than one minute. There is a skip function to jump from the current position but it has a documented restriction of approximately +or- 32 seconds from the current position. There is also a skipto function with a documented limit of up to 65 seconds from the start of the file.

The resumeMusic function allows resuming from a point relative to the beginning of the file. There is no restriction documented but in reality there seems to be a limit of about 65 seconds.

I am hoping to play podcasts & so might want the ability to jump say 30 minutes into a 60 minute podcast. I suppose I could repeatedly call the skip function 60 times but I am wondering if there is a better way?

Thanks,

Ian

[Michael P. Flaga]

There are two issue here of concern.

1) the VS1053 device is a streaming device with only 2K of memory.

2) and more important the Arduino’s SDfat library does not give access to absolute file pointer, but only the offsets from current location. And it appears the SdFat Libary is limited to 32 bit math. Not sufficient for a pointer of 4G Sdcard limitation.

The skip function uses

track.seekCur((uint32_t(timecode/1000 * Mp3ReadWRAM(para_byteRate))

and the skipto uses

track.seekSet(((timecode * Mp3ReadWRAM(para_byteRate))/1000) + start_of_music)

both a seekSet and seekCur only accept a uint32_t

That said most MP3 files want jumps to and from boundaries of the packet frame data. Jumping to the middle of a frame can cause problems, with out the header it is bunch of garbage. Neither the Arduino or the VS1053 can hold the whole file in memory. Making it awkward, as to do it right one must read the VS1053 current frame status, it will return info as to the prior and next frames, as to be properly calculated. However, it turns out that the many different formats supported by the VS1053 each have there own unique format and method of handling this information. Hence the short cut of hard jumping the offset of bytes and muting a few milliseconds as not hear the garbage until a new frame occurs.

Sorry, due to the 32bit limitation jumping is the only method that comes to mind.

FYI – I have played 2G files and not sure how it works, but it can keep going. Likely the SdCard keeps track of the file pointer, being streamed into the SPI of the Arduino.

Note that SdFat Library caches 500 byte chunks. Hence it takes a bit of SRAM. And needs a bit of time to grab next 500. But other Interrupts will take precedence.

[Anonymous]

Many thanks for your detailed reply Michael. You have clarified some things and I think I can now see the problem.

As you say, the access to the SD card is 32bits (2G) and I could not understand why this was imposing a 64k limit (16 bit) limit on jumps. But I think the problem is in the maths.

track.seekSet(((timecode * Mp3ReadWRAM(para_byteRate))/1000) + start_of_music)

I am not a C expert but is it possible that timecode * Mp3ReadWRAM(para_byteRate) is causing an overflow in the intermediate calculation i.e. before the division by 1000?  When I display the calculated values that is what appears to be happening.

I have now changed the arithmetic to remove the divide by 1000. I supply a jump defined in seconds not milliseconds and I can now jump to the middle of the file and no longer seem to be limited to 1 minute jumps.

[Author]

Posts