HDAT1 overflows while recording (VS1053)

[Stefan_N]

Hi everybody,

Is there any way in VS1053 (e.g. by reading some flag in some register) to find out if the buffer overflow occurred while writing the recorded file (the SCI_HDAT1 register overflow)?

Stefan

[pasi]

Unfortunately not. The SCI_HDAT1 value is calculated from the buffer read and write pointers. The vs1053b ROM code doesn't check for free space when it outputs, there is no overflow check.

[Stefan_N]

Thank you for your answer.

[Stefan_N]

I'm studying the 1063 documentation now and I see that for both OGG and MP3 formats we don't need to load additional programs, and the internal buffer is 3712 words (or 7.4 KB). With MP3 format and 320 bitrate, we need to write 40 KB per second, which gives about 200 ms to empty the buffer.

Do I understand this correctly?

Most pendrives do it in this time, but there are some that have cyclic lags exceeding this value.

I use CH376 to transfer data to the pendrive and ATMEGA 328 to control it.

I would like the user to be informed that the pendrive is too slow and the write will fail.
I assume that in VS1063 is no flag (like in VS1053) that would inform about buffer overflow, so we can examine the time of writing data from the buffer to the disk and based on this, detect whether this time (200 ms) has been exceeded and based on this, conclude that data reception is too slow.

Do you have any other proven method to easily and reliably know whether data reception is correct or has been disrupted?

[pasi]

Unfortunately vs1063a is similar to vs1053b in this respect. Writing data to the encoded output FIFO doesn't check the read pointer value.

If your write to storage is not blocking, you could detect overflow by the fill state going down (instead of up) on its own (without you reading from it).

Edit: there are cases where vs1063a-patches package is beneficial for encoding (see the document). There is also a smaller version vs1063a-encpatches that only contains the encoding-mode fixes.

Edit2: It looks like we can get (patch) an overflow indicator to the production version of vs1073a (probably named vs1073a2), so thanks for the question.

-Pasi

[Stefan_N]

Checking the counter status works, but only if multiple overflows do not occur. Then you may not catch the loss of one (or several) entire buffers.

But I think I will solve this problem programmatically. I am working on it.

Thanks for the information.