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?
I have a new idea. I don't know if it will work.
Re: I have a new idea. I don't know if it will work.
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
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.
Re: I have a new idea. I don't know if it will work.
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.
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