Bug in patch 1.98 for VS1053

Designing hardware that uses VLSI Solution's devices as slave codecs such as an external MP3 decoder chip for a host microcontroller.
MikeIsotech
User
Posts: 19
Joined: Sun 2013-12-22 13:52

Re: Bug in patch 1.98 for VS1053

Post by MikeIsotech » Fri 2013-12-27 16:38

Hi again,

I've solved the play first time problem by sending 2000 end fill bytes once the vs1053 initialisation is complete. Interesting that it doesn't need this for MP3 files but does for wav.

I went back to looking at the 44k wav file problem after fixing this. I checked the CLOCKF value and it is 0xB800. I checked the specification and it looks as though the maximum sample rate would be 48k with this value. I found another piece of software for the vs1053, which uses a value of 0x6000. I tried this but it didn't make it work.

I must admit that I don't fully understand what CLOCKF does, so I'd be grateful if you can comment on the value that I'm using.

Thanks,

Mike

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2727
Joined: Tue 2010-06-22 13:43

Re: Bug in patch 1.98 for VS1053

Post by Panu » Sat 2013-12-28 1:42

Hi!

Looks like you're doing good progress. Keep it up! :D

From home, let me just comment on the CLOCKF. The highest bits of CLOCKF select the PLL clock multiplier ratio: It can be 1.0, 2.0, 2.5, 3.0, 3.5, 4.0 or 4.5. A value of 2.0 means that if your crystal is 12 MHz then the core will run at 24 MHz. The datasheet tells how to set these bits.

The last 13 bits tell the VS1053 what the actual frequency of your crystal is in 4 kHz steps. This will enable VS1053 to play your files at correct speed and pitch. 0000 is a special value: it says that the crystal is 12.288 Mhz (the default value for VS1053).

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

MikeIsotech
User
Posts: 19
Joined: Sun 2013-12-22 13:52

Re: Bug in patch 1.98 for VS1053

Post by MikeIsotech » Sun 2013-12-29 0:08

Hi Panu,

Your thoughts and comments have been very useful. I've been doing some more reading, testing and thinking and I think that the problem isn't to do with the vs but with the SPI capabilities of the Arduino Uno board.

I've now discovered that 33k wav files are ok and with some tweaks to SPI settings and CLOCKF I can get 44k files sounding better but not correct. The issue that I think that I now have is that the Arduino board can't read the file and send to the vs fast enough to keep it happy. I guess I should look to see if there's a buffer under-run.

The arduino uno has a clock speed of 16MHz and the fastest SPI is clock/2, in other words 8Mhz. I have a crude test which uses a led to show activity on DREQ and it flashes when successfully playing a file but it is on constantly with a 44k file, showing that the buffer needs more data.

I think things are very close with 44k files, so I'm looking at my code for efficiency improvements, which may make the difference.

Thanks again,

Mike

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2727
Joined: Tue 2010-06-22 13:43

Re: Bug in patch 1.98 for VS1053

Post by Panu » Sun 2013-12-29 19:13

Thanks for your regards, good luck with your project.

8 Mbits/s is a high bit speed. I think you might need to run the VS1053 at 4X clock to be able to reliably receive it.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

MikeIsotech
User
Posts: 19
Joined: Sun 2013-12-22 13:52

Re: Bug in patch 1.98 for VS1053

Post by MikeIsotech » Thu 2014-02-06 16:07

Hi again,

Sorry I haven't responded recently. I had to pause on the project as other things needed to be done. I wonder if you could give me a little advice (or lesson ;) ) about data rates between an Arduino board and a VS1053, using SPI.

My project works well with 320kb/s mp3 but not 44.1kb/s wav. I wonder if you are able to tell me anything about the relative data transfer needs for those types of file? I'm trying to see whether my issue is to do with the transfer rate or whether I'm doing something wrong with the VS1053. Would it help to look at the STATUS to see if there's an under run?

I'm grasping at straws, trying to work out how I can find somewhere to start to find the cause of the problem.

Thanks,

Mike

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2727
Joined: Tue 2010-06-22 13:43

Re: Bug in patch 1.98 for VS1053

Post by Panu » Thu 2014-02-06 16:21

Hi!
My project works well with 320kb/s mp3 but not 44.1kb/s wav. I wonder if you are able to tell me anything about the relative data transfer needs for those types of file?
320 kbps MP3 file needs (roughly) 320 kilobits per second.
44.1kHz 16-bit stereo wav (CD quality) needs 1411 kilobits per second.

Usually there is no problem to transmit to VS10xx at high enough speed (5 megabps or so), the most common problem are speed issues with reading from SD card.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

MikeIsotech
User
Posts: 19
Joined: Sun 2013-12-22 13:52

Re: Bug in patch 1.98 for VS1053

Post by MikeIsotech » Thu 2014-02-06 21:10

Thanks - that certainly gives me some clues. On a very rough-and-ready calculation I must be getting around 1000 mb/s seeing as I can play 33k wav files satisfactorily.

I've just checked and the sd card that I'm using is a Class 4. I'll try a class 6 or 10, though I've heard that the SPI transfer rate doesn't necessarily improve for the higher classes.

Thanks again

User avatar
Panu
VLSI Staff. Currently on holiday.
Posts: 2727
Joined: Tue 2010-06-22 13:43

Re: Bug in patch 1.98 for VS1053

Post by Panu » Fri 2014-02-07 12:19

Right. The problem is often the BUSY time of SD card after issuing READ command and starting to get the data.

Is your SD card code using READ_BLOCK or READ_MULTIPLE_BLOCKS operations to read from the SD card? With multiple block read you get more data with just the one delay. Also if the SD card is in a different bus than the VS chip, you can probably read the whole file with just one READ_MULTIPLE_BLOCKS operation without any speed problems.

The class of the SD card has nothing to do with this - it's just an indication of the average speed of sustained write operations.

-Panu
Info: Line In and Line Out, VS1000 User interface, Overlay howto, Latest VSIDE, MCU Howto, Youtube
Panu-Kristian Poiksalo, VLSI Solution Oy

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

Re: Bug in patch 1.98 for VS1053

Post by Henrik » Fri 2014-02-07 13:23

OOPS, PANU AND I ANSWERED AT THE SAME TIME SO NOW THERE ARE TWO ANSWERS WITH BASICALLY THE SAME INFORMATION. WELL, I'LL STILL LEAVE THIS HERE.
MikeIsotech wrote:I've just checked and the sd card that I'm using is a Class 4. I'll try a class 6 or 10, though I've heard that the SPI transfer rate doesn't necessarily improve for the higher classes.
Even the slowest SD card can easily provide the data speed you require.

Does your code use the READ_MULTIPLE_BLOCKS command for the SD card? If it reads SD card blocks as individual blocks, the limits are pretty much where you currently are because after issuing the Block Read command you have to wait a millisecond or two for data to become available.

With Multiple Block Read you can go much faster because after the first block you usually never have to wait for the card to be ready: you get your data immediately.

Of course, to properly work this usually requires that the SD card is the only device on the SPI bus. If you have multiple devices, use Multiple Block Read to read 2 or 3 blocks at the time, then close the transaction and write to VS1063. With a bit of luck, even that should help you reach your goal.

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

MikeIsotech
User
Posts: 19
Joined: Sun 2013-12-22 13:52

Re: Bug in patch 1.98 for VS1053

Post by MikeIsotech » Sun 2014-02-09 23:42

Thanks both,

I hope that I understand things better now - I think that what you have said is that each time you read from the SD card there is a high set-up overhead. Reading bigger blocks will reduce the impact of that overhead.

With this in mind, I checked the hardware, my code and the arduino libraries that I'm using to see what I could find. The hardware shares the SPI bus beteen the SD card and the VS1053. In the SD library, due to the low memory available on the UNO board, it defaults to using single block reads. Even worse, the example code from the hardware supplier only reads the files in 32 byte chunks. I've based my application on this code so I assume that I getting a huge hit with repeated high overheads on each read.

My thought is that I need to look for a way to increase the number of bytes read each time to reduce the overhead. The ideal seems to be a sector of 512 bytes, but I'll need to see how that affects performance. It may be that I settle for something lower, like 128 bytes. Does this sound like the path to follow?

Thanks,

Mike

Post Reply