Let’s dance!

We have lift off! Reading the datasheet has once again proved to be the key. The SCI_CLOCKF register is initialised to 0×00 at power up. This means the decoder’s DSP is working at 12.288MHz with a max SPI write speed of 3.072MHz. The result is 2 fold; either the DSP hasn’t got enough decoding power and/or data transfers go out of sync. The ATmega328  is using it’s max SPI speed of 4MHz, roughly 1MHZ more than the decoder. You don’t have to be a rocket scientist to imagine this is a disaster waiting to happen.

VLSI recommends a clock multiplier of 3.5x resulting in the DSP running at 43.008MHz and max SPI speed raised to over 10MHz. Setting the multiplier at initialisation solved the entire problem and the dancing begins :)

A short overview of duty cycles of files tested so far (don’t forget the 328 is only clocked at 8MHz):

  • 128kpbs MP3 = 20%
  • 192kbps MP3 = 25%
  • 256kpbs 48kHz MP3 = 25 to 44% with peaks of 60%
  • 192kbps Ogg Vorbis = I would say about the same as the 256kbps MP3 based on eye sight. DREQ is so erratic my scope couldn’t get a decent lock to determine the duty cycle.
  • 256kpbs Ogg Vorbis = Same lock problem, but as expected slightly more data requests

Interestingly DREQ requests data in large blocks during MP3 playback. Ogg Vorbis playback results in much more fragmented requests, often a small one followed by a large one. Also the decoder is extremely sensitive. Just coming close with your finger will make it flip out and do strange things.

Comments are closed.