VSDSP Forum

We have experienced a problem using your VS1053 with the sample rate fine tuning.
We extract a MP2 stream from a live satellite DVB transport stream and send it to the VS1053, and then send de decoded audio (in I2S format) to an FPGA to process the audio.
We are using the last (2.9) VS1053 FLAC_LATM patch and we have activated the 15/16 resampler to use the sample rate tuning @ 48 KHz.
The nominal audio input sample rate is 48000 S/s.
The nominal audio output sample rate is 48000 S/s.
According to the "real" input rate we adapt the fine tuning in order to maintain the level of an input FIFO almost constant.
The algorithm behaves well for a time, requiring a fine tuning value quite stable (around 150).
But sometimes (something like days or dozens of days), the VS1053 seems to suddenly need a different value of tuning value (1400).
This new value seems correct for days, and then the VS1053 requires again a new value, sometimes similar to the previous, sometimes different again.
In these cases, despite the different fine tuning value, the output audio data seems to remain correct.
In some case the VS1053 requires a new tuning value too high or too low, so we can be able to maintain the FIFO at the programmed level, and the FIFO empties or fills, causing the decoded audio to get wrong.
We have measured the input rate, and it remains constant, well under 0.05 PPM, while the fine tuning value seems to change for more than 1 PPM.
Please see the attached plots of the fine tuning value (ppm*2) and FIFO filling. The horizontal scale is one point per second.
Can you give an reasonable explanation about this issue? If you need, we can provide the debug data also as csv file.

Here another measurement...
The system has running for about 20 hours with stabilized SRC and buffer value then the buffer filling increase instantaneously without any apparent reason (I'm monitoring the input stream and it has constant rate). The SRC control algo compensate the buffer filling and then goes back to initial value.
The horizontal scale is one point per second.
The two images below show full zoom and detailed zoom of the event.

Temperature (and voltage) variation affect the oscillation frequency. Capacitance also affects the oscillation frequency - how well protected is your card? Is it in a metal enclosure?

The card being a different temperature would explain some long-term variance.

During winter the air is quite dry and you will have static buildup. If not in an enclosure, would bringing your hand near the card change the playback speed enough to change the tuning value?

Changing the crystal capacitors should tweak the frequency up or down a bit. Apparently the value you use are pretty close to what they should be if you get a regular fine tuning value of 150.

The satellite is geosynchronous and we don't need to account for relativistic speeds, right?

pasi wrote: ↑

Tue 2021-02-23 16:50

Temperature (and voltage) variation affect the oscillation frequency. Capacitance also affects the oscillation frequency - how well protected is your card? Is it in a metal enclosure?

The card being a different temperature would explain some long-term variance.

During winter the air is quite dry and you will have static buildup. If not in an enclosure, would bringing your hand near the card change the playback speed enough to change the tuning value?

Changing the crystal capacitors should tweak the frequency up or down a bit. Apparently the value you use are pretty close to what they should be if you get a regular fine tuning value of 150.

The satellite is geosynchronous and we don't need to account for relativistic speeds, right?

First of all, just to clarify the system.. The VS1053 is clocked by an external 12,288MHz (not using XTAL) PLL locked to a OCXO reference.... However, the changes in temperature, voltage etc. etc. are quite slow effects...
On my consideration there isn't any "external" reason that can change rapidly the decoding speed (buffer filling). Temperature/voltage, satellite etc. changes are expected as slow up/down variation on buffer filling that should be compensated by the Fine tuning algo... (The really reason of the fine Tuning function). My algo try adjust the SRC fine tuning registers to maintains a constant level buffer filling and compensate for the effects described above.
NB: I decode an MPEG 1 Layer II stream

I'll try to stab in the dark too.

If I have understood your problem correctly, the buffer starts rising at some point of decoding and the data consumption is low. Which would look like someone turned suddenly sample rate down on VS1053. And the transition is step like.

Can you capture the stream part which gets the buffer rising? A little bit earlier before buffer rise would also be nice. Catching this kind of anomaly will be hard.

My point being that the data contains something which confuses VS1053. If the problematic data is available, it should always cause problems when it is sent to VS1053.

destmaster wrote: ↑

Tue 2021-02-23 18:27

NB: I decode an MPEG 1 Layer II stream

Is the stream guaranteed to be error-free? Are you able to store the data you send to vs1053b?

However, I would expect bit errors to cause audio frames to be discarded, and then the finetune value should become negative to play the audio slower to account for the missed data. When you see your buffer fill up, it would indicate playback to be slower than expected. (A stray write to the finetune value?)

Can you record the audio output? It could give us some clues about what happens around the time you see the buffer start to fill up. I have recently recorded very long 15+ hour captures using Audacity. (Set the default project parameters to 48kHz and 16-bit.) Saving the whole recording might be an issue, but this procedure let me look at the audio, cut away the unneeded portions and then save the relevant parts.

If the fine-tuning values are always positive (before the buffer starts filling) and fit in the lower 16 bits, writing the adjustment value should not have any race conditions either.

pasi wrote: ↑

Wed 2021-02-24 11:35

destmaster wrote: ↑

Tue 2021-02-23 18:27

NB: I decode an MPEG 1 Layer II stream

Is the stream guaranteed to be error-free? Are you able to store the data you send to vs1053b?

However, I would expect bit errors to cause audio frames to be discarded, and then the finetune value should become negative to play the audio slower to account for the missed data. When you see your buffer fill up, it would indicate playback to be slower than expected. (A stray write to the finetune value?)

Can you record the audio output? It could give us some clues about what happens around the time you see the buffer start to fill up. I have recently recorded very long 15+ hour captures using Audacity. (Set the default project parameters to 48kHz and 16-bit.) Saving the whole recording might be an issue, but this procedure let me look at the audio, cut away the unneeded portions and then save the relevant parts.

If the fine-tuning values are always positive (before the buffer starts filling) and fit in the lower 16 bits, writing the adjustment value should not have any race conditions either.

Due to nature of source the stream can have errors (poor reception under some meteorological phenomena or something like that)...
Record the encoded audio stream is a little bit difficult to to without adding modifications to the system. Also record the decoded audio is difficult because we use only the I2S output that is connected directly into a FPGA to do FM modulation.

There's some register that indicate audio frames drop count or something like that... to verify if VS1053 has discarded some audio frames?

How the better way to manage possible errors on encoded audio stream? (I need to detect and prevent to send to VS1053? I can send to VS1053... there's need to re-write VS1053 some register/s after the error occours ???)
Thanks

destmaster wrote: ↑

Yesterday 9:41

There's some register that indicate audio frames drop count or something like that... to verify if VS1053 has discarded some audio frames?

No, when there's an error, the next frame header is found and decoding continues. Fortunately Layer II frames are self-contained (layer III uses bit reservoir), so resyncing will be fast. If the bit error is outside of the bitrate field, then you miss at most 2 frames.

As a debug you could peridiocally monitor SCI_AUDATA to see if the samplerate suddenly changes (due to errors in the rate field). But a wrong rate in a single audio frame would not cause such a big data buildup you seem to be seeing.

destmaster wrote: ↑

Yesterday 9:41

How the better way to manage possible errors on encoded audio stream? (I need to detect and prevent to send to VS1053? I can send to VS1053... there's need to re-write VS1053 some register/s after the error occours ???)

There's no user intervention required.

You could try to see if transmissions errors co-incide with the strangeness you see in the fill state of the data FIFO.

pasi wrote: ↑

Yesterday 12:31

destmaster wrote: ↑

Yesterday 9:41

There's some register that indicate audio frames drop count or something like that... to verify if VS1053 has discarded some audio frames?

No, when there's an error, the next frame header is found and decoding continues. Fortunately Layer II frames are self-contained (layer III uses bit reservoir), so resyncing will be fast. If the bit error is outside of the bitrate field, then you miss at most 2 frames.

As a debug you could peridiocally monitor SCI_AUDATA to see if the samplerate suddenly changes (due to errors in the rate field). But a wrong rate in a single audio frame would not cause such a big data buildup you seem to be seeing.

destmaster wrote: ↑

Yesterday 9:41

How the better way to manage possible errors on encoded audio stream? (I need to detect and prevent to send to VS1053? I can send to VS1053... there's need to re-write VS1053 some register/s after the error occours ???)

There's no user intervention required.

You could try to see if transmissions errors co-incide with the strangeness you see in the fill state of the data FIFO.

To be sure that the issue not depends on the possibility that the incoming stream contains errors I've made another test.
I've set up another test bench (in parallel) but using the VS1063. The incoming input stream is the same for both systems(VS1053 and VS1063). I've observed that the issue happens on both system but not at same time... so this is the confirm that the problem is not related to errors or "stranges" in the incoming stream.

Another question: how fast is the SDI FIFO actually filling up? It's hard to guess from the graphs.

I think the only way for the buffer to start filling up is when the vs10xx plays the audio too slowly. This would indicate too slow samplerate. An error in the samplerate field of the mp2 stream would not do that by itself, because it would then also indicate a wrong frame size, thus resyncing and losing data, and very soon update the samplerate again according to the next mp2 frame.

The debugs I would like to see is the content of SCI_AUDATA and memory locations 0xc013 & 0xc014 (these contain the 20-bit DAC rate control value). If the reason for the SDI FIFO filling up is a wrong samplerate, we can then try to figure out how that could happen.