VSDSP Forum

First things first. I don't think this is the "high bit of the stream ID" issue, I had trouble with that initially, but was able to fix it by applying the patch.

That said, I'm using a number of OGG files that were created using ffmpeg.exe under Windows. Approximately 10% of them don't play back correctly. They start correctly, then after a few seconds of silence the player reports that it's stopped.

Full environment. I'm working with an Adafruit MusicMaker Featherwing, using an SD card to provide the music files. The Microcontroller is an ESP32-S2, using the Adafruit Feather form factor. I'm using the Adafruit VS1053 library found at https://github.com/adafruit/Adafruit_VS1053_Library . So I'll confess that I'm not crystal clear exactly how the data from the file is passed into the VS1053B. Since it will successfully play most songs, it seems reasonable to assume the error is with the OGG file itself.

I've attached an example of an OGG file that does not play correctly. If you can provide any insight into the problem, I'd be most grateful.

If all else fails, I could encode it as an AAC file instead, although I'd prefer OGG if possible. Support of AAC files would require some additional logic and changes in the playback software.

Hi,

The file plays with vs1053b-patches active (tested with version 2.9), but doesn't play without the vs1053b-patches. The serial number is 0x9dff06f8, and looking at the Vorbis-related fixed I don't see any other reason why the file would not play without the patches.

Maybe the patch upload has issues.

What is the value written to SCI_CLOCKF? Is the clock multiplier within the spec?
Also check that CVDD of vs1053b is correct (1.8V .. 1.95V).

pasi wrote: ↑Mon 2024-03-04 14:20 Hi,

The file plays with vs1053b-patches active (tested with version 2.9), but doesn't play without the vs1053b-patches. The serial number is 0x9dff06f8, and looking at the Vorbis-related fixed I don't see any other reason why the file would not play without the patches.

Maybe the patch upload has issues.

What is the value written to SCI_CLOCKF? Is the clock multiplier within the spec?
Also check that CVDD of vs1053b is correct (1.8V .. 1.95V).

As noted, I am applying the patch, since I had problems very early on with "high-bit" serial numbers. Also, the failure mode is different. To my memory, a high-bit error without the patch didn't even try, the "start playing" command returned an immediate error. With these issues, it appears to start playing correctly, but then produces typically fifteen seconds of silence, and then stops.

In addition, if it were the high-bit issue, statistically 50% of OGG files would fail to play. However, over a period of several days, playing typically 15 to 20 songs per day, the average failure rate was about 10%. This very strongly suggests it's not the high-bit issue.

That said, it's possible there's something not 100% with the patch upload, I had to take the commented out routine in the patch source and adapt it to work correctly with the Adafruit library. it's possible that something might not be quite right with that.

Regretfully, since it was happening often enough to be an annoyance, I tried transcoding all the source material to AAC, and haven't had a problem since doing so. The three advantages of switching to AAC are f1) files play perfectly, 2) I don't need to patch, and 3) I found that hard resetting the chip with the reset pin after every song (and reapplying the patch) helped OGG playback. That's no longer necessary with AAC. So even though the files are usually between 10% and 25% larger, I've switched wholesale to AAC.

Just looking at the source of the Adafruit library, SCI_CLOCKF (register 0x03) is set to 0x6000. And while I don't have the equipment (or skill) to test the voltage on the CVDD pin, I'd trust Adafruit to get it right. They take quality control very seriously.

To make matters worse, with another file that had this problem, on a second test it played fine. So it seems like it's an intermittent problem, which are often the worst type to try and solve.

Yeah, random issues are hard to figure out.

You are probably just using one board and cannot compare the operation between different individuals?