Can I change 1053 playback speed with a DDS as XTAL?

Designing hardware that uses VLSI Solution's devices as slave codecs such as an external MP3 decoder chip for a host microcontroller.
User avatar
pasi
VLSI Staff
Posts: 1433
Joined: Thu 2010-07-15 16:04

Re: Can I change 1053 playback speed with a DDS as XTAL?

Post by pasi » Fri 2017-12-29 16:20

XTALI up to 14.318318MHz will most probably work, and even above that you probably have no issues as long as the max internal clock frequency is within limits.

Vorbis decoding sets the sample counter to specific values when it knows 'where it is'.

SampleCounter of the vs1053b patches package advances for each DAC interrupt whether there is a sample waiting or not. So, you should get a steady increment by samplerate each second. The first increment per 10s is 438040, the following are either 441363 or 441319 (only twice, each time 44 samples less, which means 1ms), so seem very steady. From 10s to 90s we get 44134.6625Hz, which is only 0.08% from nominal, which can be accounted by crystal frequency difference.

So, it looks like the issue appears just at the beginning. Could you do a read after each 500ms without clearing the sample counter at the beginning? If you read the first time just before sending data to SDI, you should get a few too many samples in the sample counter.

If there are audio underflows, the sample counter does not correspond to the decoded sample. You can read the number of audio underflows from Y:0x1a82 (WRAMADDR=0x5a82). Write 0 somewhere at the beginning.

User avatar
Henrik
VLSI Staff
Posts: 1058
Joined: Tue 2010-06-22 14:10

Re: Can I change 1053 playback speed with a DDS as XTAL?

Post by Henrik » Tue 2018-01-09 12:23

Hello!
fwachsmuth wrote:
Thu 2017-12-21 16:47
It's year-end break time, so finally I got time for this project again. :)

To whom it may concern, I think there is a mistake in the 1053b patched PDF on page 12:

Code: Select all

unsigned long Read32BitsFromSCI(unsigned short memAddr) {
  unsigned short msbV1, lsb, msbV2;
  WriteVS10xxRegister(SCI_WRAMADDR, addr+1);
  msbV1 = (u_int16)ReadVS10xxRegister(SCI_WRAM);
  WriteVS10xxRegister(SCI_WRAMADDR, addr);
  lsb   = (u_int32)ReadVS10xxRegister(SCI_WRAM);
  msbV2 = (u_int16)ReadVS10xxRegister(SCI_WRAM);
  if (lsb < 0x8000U) {
    msbV1 = msbV2;
  }
  return ((u_int32)msbV1 << 16) | lsb;
}
This should use either addr or memAddr, but not both, correct?
You are quite right. The document will be corrected when the next patch version is released.

Kind regards,
- Henrik
Good signatures never die. They just fade away.

User avatar
Henrik
VLSI Staff
Posts: 1058
Joined: Tue 2010-06-22 14:10

Re: Can I change 1053 playback speed with a DDS as XTAL?

Post by Henrik » Tue 2018-01-09 12:49

Hello!
fwachsmuth wrote:
Thu 2017-12-28 16:18
I made a 100 second m4a file with 44.1kHz. When playing it back, the sample count register is at about 4405286 (+/-200) at the end, so it somehow missed some samples. However, the playback time of rendered output is exactly 100 seconds long (I recorded the 1053 output with a DAW to verify).
What you are seeing is actually normal, and, rest assured, no samples are missed.

Let me explain. When you have sent the last bytes of the m4a file to VS1053, it hasn't fully played yet. The last kilobyte of your file is still waiting for processing in the VS1053 bitstream buffer. Even when the bits have been completely decoded, it will take an additional 2048 stereo samples before the file has fully come out of the audio buffer. So, even after you have sent the whole file, it will still play for a while. All of this can easily explain the discrepancy of a few thousand samples you are seeing, or even more for a low-bitrate stream, e.g. an 8 kbit/s mono 24 kHz MP3 file could show an "error" of up to about 25000 samples.

Kind regards,
- Henrik
Good signatures never die. They just fade away.

fwachsmuth
User
Posts: 13
Joined: Sun 2016-01-10 14:58

Re: Can I change 1053 playback speed with a DDS as XTAL?

Post by fwachsmuth » Sat 2018-01-13 14:28

Thanks, guys. I am making serious progress now. :)

Post Reply