Who has some experience with VS10xx decoder chips?

Patrick1ab · 2010-03-30 21:37

I'm trying to work with VS1053 decoder chip, but I've got the following problem:

While I'm playing a file, I would like to allow the user to change volume, bass, treble, balance, etc. , but since my program uses multiple cogs it seems, that sometimes command instructions are mixed with data instructions (klicks and beeps in the sound output).
Now I tried to include the command instructions into the cog which also sends the data instructions and set a status variable to tell this cog what it has to do next.
This seems to work somehow (the klicks and beeps are gone), but know some commands which worked before, are not sent anymore (for example: stop)
Another problem is, that now the volume level sometimes jumps instead of increasing/decreasing linearly.

Okay, now it works.
During playback the cog which sends the data instructions is now also processing the command instructions (with some exceptions).
I also made a few changes to the MP3 decoder driver to ensure that values (RegValue and RegName) aren't overwritten if procedures are called by two different cogs.

So, this is already working:

- IR remote control input and LCD connected to a port expander
- creating and displaying a filelist from SD card with cursor navigation
- playback with display of the time
- pause
- stop
- volume change (with no interruption during playback)
- jump to next file / previous file during playback

This is implemented, but still needs some bug fixing:

- change of bass boost, treble and balance
- playback of MIDI files does not work; maybe I've got the wrong file types on my SD card?

and this still has to be done

:

- changing filelist from static to dynamic using malloc to assign memory
- allow change of directory
- allow long filenames (wasn't there something in old DOS versions where files got a "~" + number at the end?)
- fast forward / rewind
- more information displayed during playback (bitrate, ID3Tags?)
- ability to create a playlist
- finding / opening shared files on a network (I've got absolutely no idea how this works!!!)
- opening internet radio streams (I'll need more memory to buffer the incoming data -> SPI SRAM)
- and I'm probably going to connect an external DAC to the VS1053 (hmm...Wolfson... *sigh*)

If someone is interested, I'll post my source code; although it looks awful

Post Edited (Patrick1ab) : 4/2/2010 1:26:00 AM GMT

jmspaggi · 2010-07-27 14:41

Hi Patrick,

I'm VERY interested by our code [noparse];)[/noparse]

Was you able to make some progress on it?

My goal is to add a OGG player in my car. The VMusic2 is not decoding OGGs, so look like my best option will be to go with the VS1053.

I will order the breakout board today and try to play with it. I hope you will be able to share your code. That will help a lot.

How many cogs will this require? Because I already have some cogs dedicated to other cr controls [noparse];)[/noparse]

Thanks,

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

FMMT666 · 2010-07-27 15:15

Patrick,

I don't know the VS1053, but I already created an PASM/SPIN object for the VS1011e.
It includes tone control, fast forward/rewind, etc...

Only limitation is FSRW, which limits file names to 8+3 as well as the max. number of files
(without any dirs). I really count on rokicki and lonesock to finish this one

Maybe some of the code can be helpful...
www.askrprojects.net/hardware/promp3ller/index.html

AS

jmspaggi · 2010-07-28 23:23

Hi AS,

Can you point me to the right position on your code?

Regarding the limitation, what is FSRW?

For the filename 8+3, I will build a catalogue outside of the Prop and put it on the SD, then I will read it instead of the filename itself.

Also, regarding the number of files limitation, how many files can we have in a directory?

Thanks,

JM

Timothy D. Swieter · 2010-07-29 05:42

You could use Kye's SD card driver which has directory support.

Tell me more about the hardware design for your systems guys. Show some pictures. Is the Prop connected to the SD card and pulling MP3 data and feeding it to the VLSI IC or is the VLSI IC connected directly to the SD card?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

jmspaggi · 2010-07-29 12:26

Hi Timothy,

I don't have any picture yet since I'm still waiting for all the components to arrive, but I will post them as soon as I can.

I will connect the SD reader and the VLSI both to the propeller. So the propeller will allow me to use a display to show files names, files comments, choose with track to player, etc. Then the prop will send the flow to the VLSI via UART, and the VLSI will play it.

That's the plans, but it does'nt meant that will be the final schema [noparse];)[/noparse] I should received all of that over the few next days. So I hope to start to put all of that together over the next 3 weeks.

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

FMMT666 · 2010-07-29 23:29

jmspaggi said...

Can you point me to the right position on your code?

Regarding the limitation, what is FSRW?
For the filename 8+3, I will build a catalogue outside of the Prop and put it on the SD, then I will read it instead of the filename itself.

Also, regarding the number of files limitation, how many files can we have in a directory?

JM,

which particular section do you mean? Tone control?
In "promp3ller_V03.spin", look out for:

  ChainSetSound(tVol,tFreq,bVol,bFreq)
  ChainSetVolume(left,right)
  ChainWriteSCI(addr,value)
  ChainReadSCI(addr)

These can be called any time, even while audio is playing.
The VLSI command bytes are "chained" into the audio stream.

In the PASM section:

  aWriteSCI
  aReadSCI

FSRW? It's a nice, easy and almost ready to use object for SD-card
interaction. Look here:
fsrw.sourceforge.net/

There's another one from Kye (Timothy mentioned it):
http://forums.parallax.com/showthread.php?p=912403
I did not yet find time to test or implement it.

FAT16 allows a maximum of 512 files in the root directory.

Yes, I had the same idea, a file that contains all the song names.
But this can be tricky during audio playback because you will have at least
two files opened during that time. At some point, the audio playback gets choppy.
Right now, my workaround consists of a buffer in RAM, containing the filenames...
Not that nice 8(
I just started developing an EXT2 file system object to overcome all those FAT
limitations...

Timothy said...

Is the Prop connected to the SD card and pulling MP3 data and feeding it to the VLSI IC...

Of course! Did you expect anything else?

AS

jmspaggi · 2010-07-30 00:30

An Ext2 driver will be awesome!

Regarding the VLSI chip, if I understand correctly what you said, that mean I need to have only 1 cog sending information else I will have some issues, correct? So I can send SDI and SCI data back to back, still correct?

I took a look at you code. In ChainWriteSCI, you are putting the command on your vSCI "stacks", but I was not able to find the cog which is sending it to the VLSI. Is it in gogogo?

I'm new in propeller Spin (coming from Javelin), so this will be a nice challenge for me [noparse];)[/noparse] Even if it takes time, I will do it! [noparse];)[/noparse] But if I can reuse some code, that will help me a lot.

Regarding the files, I did not figured we can only access one at the time! That might be an issue. Because my girlfriend put barely all her files in a single folder! So I don't want to keep the entire list in memory, and I want to allow the user to change directories.

On Kye's driver, there is changeFilePosition method. Wich will allow me to close the OGG, open the catalogue, read it, close it, open back the OGG file and go back to the positions where I was. The question is, will all of that be fast enought? Not sure. But with some buffering, it should be.

I will test all of that soon. I will probably open a specific thread for my newbee project [noparse];)[/noparse]

Thanks again for sharing your knowledge!

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

Timothy D. Swieter · 2010-07-30 05:28

AS -

It has been a little while, but I thought when I reviewed VLSI IC before that the IC could hvae the SD card connected directly to the IC instead of having to go through a microcontroller. However, maybe that was a different IC as they have several flavors of ICs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

jmspaggi · 2010-07-30 11:13

@Timothy:

I think this is an option available on the ship. I think he can use the SD Card directly, but that way you have less control and no display.

I still have to read all the documentation to be sure.

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

FMMT666 · 2010-07-31 00:35

Timothy,

yes, you are absolutely right. The SD card could be directly connected to the VLSI.
But, what about all the all the additional features and fun, a Propeller provides?

And as JM stated (and a little more):
No display, no network, no radio, no upload, no FFT, ...

AS

Timothy D. Swieter · 2010-07-31 06:01

I guess it just depends on the application and what you want to do. You could connect the SD card to both the VLSI and the Propeller. On startup, the Prop keeps VLSI in reset and then the Prop can read tracks/titles, and configuration info off of the VLSI. Then it starts the VLSI and it can handle the song file playing without much trouble from the Propeller while it is doing other work (or powered down and sitting around).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, P.E.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

jmspaggi · 2010-07-31 11:08

Hum.

Interesting! That way you don't have to worrie about "feeding" the VLSI with the music file data... And that will free a cog, with the same behaviours...

Update: And that will also free-up some memory which will allow you to have a beter displayl.....

Now because of you I will have to look at this option! [noparse];)[/noparse] I don't know if the VLSI can be given the file path but if that's the case, it can simplify the thinkgs...

JM

Message Edité (jmspaggi) : 7/31/2010 11:14:15 AM GMT

FMMT666 · 2010-07-31 11:44

And always remember, these chips are not just decoders (-;
The "new", complete toolchain incl. an IDE, is here:
www.vlsi.fi/en/support/software/vside.html
I am still using the old v1.2 version, but will give the new one
a try next week.

New support and discussion forum ("growing" 8-), here:
www.vsdsp-forum.com/phpbb/index.php

AS

jmspaggi · 2010-08-01 01:51

Was not aware of this IDE... What does it allow? Have you already tried it?

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

jmspaggi · 2010-08-03 15:40

Hi AS,

Just a quick question. When the VLSI is playing the file, do we have a way to know the file duration, and where we are at? Like a way to display "1m12 / 3m57"?

Thanks,

JM

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Linux? There is worst, but it's more expensive.

FMMT666 · 2010-08-03 23:09

The command

  SCI_DECODE_TIME

returns the current decoded time in seconds.
This register is read- and writable.

The length of a song can not directly be read out from the VS1011e.
At least, MP3 is a streaming format. A song may continue forever...

An option would be:

a) reading the MP3 tags
b) estimating the playing time from sample rate and file length (not for variable rates)
c)... ???

(I never used an absolute time, but the percentage of bytes-written/bytes-total.)

But indeed, this is an interesting question!

gone-reading [noparse];)[/noparse]
AS

jmspaggi · 2010-08-03 23:28

Hi,

For Ogg files, seems that there is also the "positionMsec" value which is precise since it's encoded into the file itself. So fast forward will not corrupt it.

Regarding the duration, if I can get the data rate in bytes per seconds, and if I know the file sice, I should be able to calculate the song length, no?

I have not yet received my VLSI so I can't do any testing, but will probably when I will have it...

JM

UPDATE: average data rate for Ogg files is in SCI_HDAT0...

Who has some experience with VS10xx decoder chips?

Comments