VS1053 sample rate fine tuning value changes after a while

[destmaster]

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.

Hi,this the a zoomed buffer filling condition... X axis scale is 1 second. The nominal bitrate is 160kbps

buf.png (171.61 KiB) Viewed 243 times

As you suggestion, I will try to add registers debug to figure out if something happens.

[destmaster]

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.

Hi,this the a zoomed buffer filling condition... X axis scale is 1 second. The nominal bitrate is 160kbps
buf.png
As you suggestion, I will try to add registers debug to figure out if something happens.

Here the measurement with debug info...

buf.png (127.04 KiB) Viewed 237 times

as you can see the SCI_AUDATA value changes .. What can be the reason?
This is the SRC adjust routine.... Is the only SW point where SCI_AUDATA is written...
void AdjustRate(int32_t ppm2)
{
VS1053_Write_Reg(SCI_WRAMADDR, 0x1e07);
VS1053_Write_Reg(SCI_WRAM, ppm2);
VS1053_Write_Reg(SCI_WRAM, ppm2 >> 16);

// oldClock4KHz = 0 forces adjustment calculation when rate checked.
VS1053_Write_Reg(SCI_WRAMADDR, 0x5b1c);
VS1053_Write_Reg(SCI_WRAM, 0);

// Write to AUDATA or CLOCKF checks rate and recalculates adjustment.
VS1053_Write_Reg(SCI_AUDATA, VS1053_Read_Reg(SCI_AUDATA));
}

When the issue happens also the 0xC014 register changes... in normal condition remains stable and only 0xC013 changes.
The SCI_AUDATA reports the input or output sample rate? Why 0xC013 and 0xC014 seem larger then 20 bit? What DAC value is this? Remember that we use only the I2S..

[pasi]

I think there is one race condition that could happen with the current AdjustRate() function and bit errors in the mp2 header.

1. Bit error happens, mp2 decoder sees the rate is different than in its previously decoded frame and sets rate, SCI_AUDATA is written.
2. AdjustRate() reads SCI_AUDATA.
3. mp2 decoder encounters the next frame header with the correct rate bits (48000Hz), notices it's different than what it has set before, thus sets rate, SCI_AUDATA gets written.
4. AdjustRate() writes SCI_AUDATA with the wrong value.
5. mp2 decoder is happy that all of the next frames have the same rate, so it doesn't set rate until the next change in the rate.

If you know the rate will be 48000Hz, then using that as a constant is worth a try, ie. use VS1053_Write_Reg(SCI_AUDATA, 48000U); in AdjustRate();

In the least you could try the above to see if that removes the issue.

Edit: 0xc014 also contains PLL control bits. The 16 bits of 0xc013 and the lowest 4 bits of 0xc014 are the DAC control value.

Other decoders than mpeg layers 1 to 3 tend to look at the current hardware rate (instead of an internal copy), so they don't have the same "feature". Most other decoders also set the output rate only once per file.

[destmaster]

Thank you for your suggestions... I will try to do it.