VS1053b streaming: slow data request using SRC

[destmaster]

Dear support,
I'm using the VS1053b with patch 2.4 with FLAC plugin. My application decode an MPEG2 (MPEG1 layer 2) audio streaming coming from satellite. An FPGA extracts the ES from the satellite transport stream and puts in a FIFO. This FIFO is read by an MCU that fills a local buffer. 32 bytes of this buffer will be sent to the VS1053 at every DREQ request.
Because the sample rate is 48KHz the 15/16 converter is enabled to permit samples speed up/slow.
A software algorithm on MCU monitor the MCU local buffer filling and adjust the speed of the VS1053 (by changing the SRC value) to maintain the MCU buffer filling at desired value.

The algorithm seems to work fine.

VS1053.jpg (243.91 KiB) Viewed 3122 times

See picture: the green plot is the buffer filling (1500 bytes is the desired value), the blue is the SRC value.

The problem is that sometimes, with randomly frequency (between minutes/hours/ days), the MCU internal buffer became FULL although the sample rate converter speeds up the playback.

VS1053_issue.jpg (133.62 KiB) Viewed 3122 times

See picture (The SRC value is limited by software to +-500 to prevent overflows, however in a previous version this value is not limited and the problem was the same). The MCU buffer is fill at 10*1024 bytes (buffer size). The audio output seems correct and after a period the buffer slowly goes down a correct filling level (1500 bytes) and continue to work good up to next issue condition. When this issue occurs, sometimes, I haven't no audio at VS1053 output.

Monitoring the VS1053 internal buffer using the functions:
VS1053bStreamBufferFillWords()
VS1053bStreamBufferFreeWords()
VS1053bAudioBufferFillWords()
VS1053bAudioBufferFreeWords()
VS1053AudioBufferUnderflow()

seems that aren't any difference in these values between normal condition and buffer full condition....
There's a function to know if an internal VS1053 buffer's overflow occurs?

I've put an oscilloscope on DREQ pin to observe the rate of the data request. The oscilloscope was triggered on ES data start at FPGA side.
I' noted that on normal working condition the DREQ data request signal jitter around the trigger signal.
When the issue occurs and no audible issue are present (audio seems to work fine), I've seen that the DREQ data shifts slowing...
When the issue occurs and no audio output , the DREQ pin goes high at very slow rate (around one time at second...)

Have you an idea about what happen?
Can I do more test to investigate the cause of this issue ??
Thanks
Giuseppe

[pasi]

Hello Giuseppe,

These are probably different issues.

You say you're adjusting the SRC value. Are you doing it by directly writing to 0xc013 and 0xc014 or using the samplerate finetuning of the vs1053b patches package?

It is possible one modification of the samplerate registers gets partially overwritten by another occurring exactly at the right moment and results in a very low samplerate.

If you read 0xc013 and 0xc014, do you get sensible values? (Write 0xc013 to WRAMADDR, read twice from WRAM.)

[destmaster]

Hi Pasi,
To modify the sample rate I use the fine tuning by using this function available with Patch 2.4 (15/16 resampler is also enabled)

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));
}

[pasi]

What is you SPI speed and what is CLOCKF when you read SCI_AUDATA?

Could you add a debug print of the value you read from AUDATA? Also, write 0xc013 to WRAMADDR, read twice from WRAM and print those values.