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

[pasi]

Chapter 1.3 of the vs1053b patches document. The sample counter is at X:0x1800/0x1801 when the patch is loaded and started.

[fwachsmuth]

Thank you so much. That will be my challenge for the coming weekend. Kiitos!

[fwachsmuth]

One more question: The documentation suggests that this value is only accurate for Ogg Vorbis files, but "free-running" for other filetypes.

Does "free-running" mean that I can not use it to determine an absolute playhead position? Or would it work for CBR mp3 files, but not VBR?

Being limited to Ogg Vorbis files only would be quite a limitation for my intended use case... I thus hope I misunderstand the documentation. Any luck?

[pasi]

For other formats the counter indicates the number of samples played, so it corresponds to the file playback position as long as there are no underflows in the DAC FIFO.

Ogg Vorbis contains a field containing the absolute sample position, which will periodically update the sample counter even if the DAC FIFO underflows during playback. Note that the sample position may not start from zero.

[fwachsmuth]

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?

[fwachsmuth]

I got one more question.

In my application, it would be beneficial if I could speed-up playback by up to approx. 33%.
If my math is right, I would need a 15 MHz XTAL: 15000000/256/44100-1 would give me a 32.87% speed increase. The datasheet lists 13 MHz as "absolute maximum" though. Is this maximum defined to maintain normal playback speed? Or is it due to reliability?

In other words: Can I safely use a 15 MHz Xtal (plus the 15/16 resampler) or better not?

Would be nice to know before I start soldering.

[fwachsmuth]

Hey pasi, all,

I ran into a weird problem when trying out the Sample Counter Register (with patches 2.5.0 loaded) today.
When I write '0' to 0x1800 and then read a long from 0x1800 as described (with MSB-savvy, self-correcting code) and devide the returned value by runtime, this is what I get when I play back a 2 sec "beep" mp3 file with 44.1kz Sampling Rate and divide the counter by runtime every 10 seconds:

Code: Select all

Sample count:       0 after 0 ms, so nan Samples / Sec
Sample count:  438040 after 10000 ms, so 43804.00 Samples / Sec
Sample count:  879359 after 20000 ms, so 43967.95 Samples / Sec
Sample count: 1320722 after 30000 ms, so 44024.07 Samples / Sec
Sample count: 1762041 after 40000 ms, so 44051.02 Samples / Sec
Sample count: 2203404 after 50000 ms, so 44068.08 Samples / Sec
Sample count: 2644768 after 60000 ms, so 44079.47 Samples / Sec
Sample count: 3086087 after 70000 ms, so 44086.96 Samples / Sec
Sample count: 3527450 after 80000 ms, so 44093.12 Samples / Sec
Sample count: 3968813 after 90000 ms, so 44097.92 Samples / Sec

The same happens with longer tracks: During playback, I seem to lose hundreds of samples every second.
Obviously, the counter keeps increasing after the track has finished -- which is why I am nearing 44.1kHz over time.

You mentioned earlier this year that the counter is "free-running" with non-ogg files, so "indicates the number of samples played, so it corresponds to the file playback position as long as there are no underflows in the DAC FIFO". The part in italics is a bit ambiguous: Does the register represent the # of samples actually played, so can I use it after a second to determine where my playhead actually is? For example, after the first ten seconds of the above test, only 438040/44100 = 9,932879818594104 seconds of music would have been rendered (and taht would be my "playhead position". Is this assumption correct?

At least I don't understand why the counter would be below 44100 after exactly one second if skipped frames would not matter. That's the part of "free running" that I don't understand. Or is it only "free running" if the track has finished playing?

[fwachsmuth]

Any word on this? I need a reply to continue my project...

[Panu]

Hi!

I don't really know enough to answer the last questions in your posts, but maybe I can write something that might be useful. Most people at VLSI are on holiday right now...

The datasheet lists 13 MHz as "absolute maximum" though. Is this maximum defined to maintain normal playback speed? Or is it due to reliability?

It comes from chip characterization and production testing. All chips' performance follows a bell curve; some chips are faster and some are slower. What we do in production is characterize the chip extensively around a small number of operation points and then make production tests that are designed to guarantee, as accurately as we can, that chips that can't meet that criteria are discarded in production.

VS10xx "natively" runs at 12.288 MHz and higher frequency is generally not needed. But, as 13 MHz is a GSM frequency, and it might be a convenient xtal frequency for handset manufacturers to use, we've chosen that frequency as the operating point where we characterize the IC. It's also the frequency which we promise the chip to work at. But then again, reality is that all chips have a maximum operating freqency which is also a function of the operating voltage. With higher voltages the chip can work at higher frequencies. In practicality, given enough voltage, probably almost all VS1053 chips will run at 15 MHz at that voltage, so also your chip probably will... but we absolutely will not guarantee it. Because, due to probability, there's always a few chips that will not go so fast.

-Panu

[fwachsmuth]

Kiitos, Panu, for the insight. I will try out with mine.
Happy holidays to you all, and I‘ll wait patiently for some insight from Pasu regarding the sample count register.

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).

When I continously fine-time the sample rate to achieve a „measured“ 44100 samples/sec (which requires an average correction value of 352 to ppm2) the rendered output is a bit too short.

This is so weird.

I am really close, but need to understand what the sample count register exactly contains when playing back something else than ogg files.