I have a new idea. I don't know if it will work.

Discussion about writing software for VS1005 and the VSOS Operating System. Also posts about VS1005-related hardware design and device drivers should be posted here.
Post Reply
winwan
Senior User
Posts: 55
Joined: Fri 2014-07-04 15:51

I have a new idea. I don't know if it will work.

Post by winwan »

viewtopic.php?p=14690#p14690
HELLO Henrik:
I have a new idea. I don't know if it will work.
TF card interface (or SPI), from master mode to slave mode, is VS1005 file system is not used, TF card /SPI interface passively receive audio file streams (maximum support DSD256 file streams), and then decode. Does this save a lot of running resources? The advantage of this is that the audio file system can be attached to another chip to complete the 1005 decoding efficiency and stability is better.
It seems that 1053 already implements this functionality, reading audio file streams from SPI and decoding them?
Evaluate it and see if it works?
User avatar
Henrik
VLSI Staff
Posts: 1268
Joined: Tue 2010-06-22 14:10

Re: I have a new idea. I don't know if it will work.

Post by Henrik »

Hello Winwan!

I see what you mean.

Yes, it would actually be possible to decode DSD on VS1005, then send decoded PCM data to e.g. VS1053 using SPI, then VS1053 could run the equalizer (VS1053b PEQ Plugin at http://www.vlsi.fi/en/support/software/ ... ugins.html).

If cost is no issue, another alternative would be to connect two VS1005's with I2S: The first one decodes DSD and uses I2S to output audio, the second VS1005 receives I2S, then runs the equalizer and output to its own DAC analog output or I2S to external DAC.

Kind regards,
- Henrik
Good signatures never die. They just fade away.
User avatar
pasi
VLSI Staff
Posts: 1963
Joined: Thu 2010-07-15 16:04

Re: I have a new idea. I don't know if it will work.

Post by pasi »

Unless you perform sample-rate conversion, I2S would be a little awkward with DSD though, because I2S is usually 48kHz multiples due to the 12.288MHz crystal, and DSD is is 44.1k-based.

SPI would not be without its own issues either, e.g. keeping the correct synchronization for left/right data, and identification of the samplerate (when using burst transfers it's not straightforward to determine the data rate and derive the samplerate from that).

One workaround would be to use a simpler EQ (less CPU) with DSD128+ decoding and the better EQ with other formats.
Visit https://www.facebook.com/VLSISolution VLSI Solution on Facebook
Post Reply