vs1053 fast forward problem

[zulunation]

Hello,

I am using vs1053 to play music.
There is a problem with fast forwarding.
When fast forwarding I am using steps from 9.5.4 in datasheet.
I wrote a simple test.
I am reading the mp3 file into a buffer.
After that I am sending it to vs1053. It plays well.
There is a counter which couts bytes which are sent.

In the middle when couter reaches certain value I am sending not the i+1 byte but
i + 100 byte and all bytes next. I am emulating the fast forward. So there is a glitch in an output.

Next before sending the i + 100 byte I am sending 2048 bytes of zeros.
I have noticed that for mp3 file endfillbyte is 0. Also SS_DO_NOT_JUMP is never set.
So i am just sending zeros to decoder.

After that I am sending i+100 byte and next bytes after it (i + 101, i + 102 and so on).
But there is still the glitch in an output.
I was expecting that sending zeroes are resetting the decoder and he will
be playing next part from start like nothing was sent before.

Maybe there is any additional check to make sure that decoder is resetted?

PS: I am not lowering the volume. The datasheet recommends to lower the volume.
Why this must be done? I was expecting that sending endFillbyte will reset the decoder
and no glitch will be at the output.

Thanks,

[pasi]

If you don't follow the mp3 frame boundaries, you will get decoding errors on the partial frames. (The vs1053b patches package tries to improve on this by adding a bit reservoir check, but it still won't be perfect.)

vs1053 has a better way to fast-forward than skip some bytes (which is dependent on the bitrate). See the playspeed field of the parametric_x structure. See 10.5.3 Fast Play and 10.11 Extra Parameters from the vs1053 datasheet.

[zulunation]

Hello,

Thanks for reply

I want to understand one thing.
If decoder is decoding the mp3 frame and I send not i+1 but i+N byte there will be a glitch at the output because decoder
is decoding a wrong data.
But if we reset the decoder after 1+1 byte? Reset in a sense that make decoder decode from beginning.
I guess that endFillByte which must be sent to decoder is resetting the decoder.
Am I correct?

[pasi]

VS1053b reads whole mp3 frames, then decodes them (frame decoding cannot be interrupted, not even with SM_CANCEL), then plays the decoded audio. Decoding errors cannot generally be detected, there is no checksum and there are no "holes" in the code space, so the decoded frame is then simply played back. 0-bytes are generally the best value to minimize the effects of decoding errors, so it's recommended to send them when you cancel/jump in a mp3 file.

This was improved in vs1063a. To play the just decoded frame, vs1063a checks that a valid frame header is following the current frame (but it also allows zeros between frames). So, for vs1063a you would set SM_CANCEL, then send non-zero bytes. This causes the decoder to discard the just decoded frame without playing (because it doesn't detect a valid mp3 header or zeros following) and returns from the decoder and starts looking for a new audio format.

Resetting the decoder in vs1053b can be done by software reset (or restarting the vs1053b patches if you have that loaded), but you will then also lose some already decoded audio from the audio FIFO. Also, this is only viable for mp3, because you can then restart sending at any point of the file. This doesn't work with most of the other formats, because they need the header.

Have you tried the Fast Play feature? Is it suitable for your case?

[zulunation]

Yes FastPlay will be suitable.

But I forgot to mention that I also need rewind back. This is more complicated.
So as I am understood sending endfillbyte should reset the decoder so then when we will send another frame there will
be no glitch.
But there should be glitch because you recommend to lower the volume before rewind.

[pasi]

There is a trade-off between easyness and error-freeness in jumping backwards in a mp3 file.

The easy way is to just jump in the new location and let the decoder resynchronize. You will get some decoding errors.

If you decode the mp3 headers yourself (the 4 first bytes contain all of the required data), you know where each mp3 frame starts and ends. You can store some of the exact locations to jump to for rewind, and you also know to stop sending data exactly at the frame end, so that there is no decoding error.

Is the rewind a 5sec / 10sec / 20sec jump once per user input?

[zulunation]

You will get some decoding errors

These decoding errors mean glitch at the output?

I have vs1053b chip. And I don't load any plugins into it.
There is no mentions in datasheet about plugins.

I made an experiment today.
After reset I started to play mp3 file but not from beginning but from different offsets.
And I found that for some offsets I hear a glitch at the beginning.
I don't understand why that is happening?
What happens when we feeding the frame not from beginning but from the middle.
I was thinking that decoder will ignore this frame and wait until it get header from the next frame and there
will be no glitch at the output.
But I heat the glitch.

[pasi]

What happens when we feeding the frame not from beginning but from the middle.

The decoder finds the next location that looks like a mp3 header, then decodes and plays it. However, there is this "bit reservoir" option where the mp3 frame can reference data a the end of the previous frame. The vs1053b decoder doesn't keep track of this.

So, you can still get a glitch with vs1053b if
a) the bytes that looked like a mp3 header were not an actual frame header
b) the frame uses bit reservoir.

The mp3 decoder in vs1063a keeps track of the presence of the bit reservoir data, and also tries to help the correct detection by looking for the next frame before it plays the decoded result.

The vs1053b patches package also tries to keep track of bit reservoir. See https://www.vlsi.fi/en/support/software ... tches.html . The patches package also contains other fixes.

[zulunation]

Hello,

I have solved the problem in a simple way before rewind/fast forward I lower the volume. And after restore it back.
Sounds pretty well.

But I faced another problem after long testing. I don't want to create another topic for it.
Sometimes during mp3 play I see that DREQ goes low and stays there forever.
It happens rear but a bit problem to me.
I have checked that I respect DREQ and sending only after DREQ goes high.
I am using maximum clock CLKI multiplier but SPI write speed is 12 MHz within the limit.
Maybe there is errata on that chip?
Maybe there plugin posted above fixes some problems?

[pasi]

Timeout and software reset should help.

If the decoder stays stuck with DREQ high, what does HDAT1 contain? The mp3 decoder should not get stuck. If there are errors for other formats, there is a larger possibility of getting stuck.

If the mp3 file contains an ID3v2 tag, then it may take a long while to skip the data (e.g. album cover art), or worse, an audio format erroneously detected from the data and causing a crash.

The vs1053b Patches package has some fixes.

Check that GPIO0 and GPIO1 are pulled low (or both high), otherwise vs1053b may sometimes enter the Real-time MIDI mode. You should see 0xac45 in AUDATA in that case.