Hi soundcheck,
We extract the header information and rejected the RIFF format as we only support canonical WAV format.
I was only attempting to explain what my brother (who wrote the SD-player software) told me about this subject. Obviously I failed to do so.
We extract the header information and rejected the RIFF format as we only support canonical WAV format.
I was only attempting to explain what my brother (who wrote the SD-player software) told me about this subject. Obviously I failed to do so.
John -- once more. I don't think the issue is solved.
Cannonical WAVE is a subset of RIFF. Cannonical WAVE uses the RIFF frame. That's the same for all standard .wav. wavpcm is a different animal.
I hope this clarifies the issue.
🙄 I think you mixed things up. If that's what you mean with "Obviously I failed to do so" . 😉
Your comment "Onno" uses RIFF and you use .wav doesn't make any sense.
Cheers
The SD/ISD-player has been working fine for quite some time now, except from the minor "issue" that required file conversion, the unit has been working flawlessly with SDHC cards up to 32Gb.
One can discuss possible issues with file formats, but fact is that in the very rare case such a file is used, it can be easily converted so it works with the SD-transport. The ECDSD program has already been modified so it will automatically convert to canonical WAV format.
New developments,
Feature to print booklets with CD artwork of SD(HC) card contents is added to the ECDSD program.
SD/ISD player DAC module has been upgraded to TDA1541A-MK3 version.
I received questions about connecting the SD-transport to external DACs, the 32 bits / frame seems to be a bottle neck.
So I decided to develop a SD-transport (SD-player without integrated DAC) for use with all external DACs that support SPDIF.
The unit is based on the existing SD-transport module.
In order to maintain lowest possible jitter at the external DAC, the SD-transport can be slaved with a blank SPDIF stream transmitted from the external DAC. Masterclock can then be located close to the DAC chip. If the SD-transport detects no external clock, it uses the internal clock.
The SD-transport can run on both, small mains adapter or battery.
I am planning to use Toslink for both I2S out and I2S in (slave mode) in order to get perfect galvanic insulation and offer plug and play compatibility with external DACs.
The cheapest version will only have remote control (no keys).
Display is same as on SD-transport, large white LED display with excellent readability with color filters for different display colors.
The SD-transport housing is same quality (aluminum) as the SD-player with integrated TDA1541A-MK3 module.
One can discuss possible issues with file formats, but fact is that in the very rare case such a file is used, it can be easily converted so it works with the SD-transport. The ECDSD program has already been modified so it will automatically convert to canonical WAV format.
New developments,
Feature to print booklets with CD artwork of SD(HC) card contents is added to the ECDSD program.
SD/ISD player DAC module has been upgraded to TDA1541A-MK3 version.
I received questions about connecting the SD-transport to external DACs, the 32 bits / frame seems to be a bottle neck.
So I decided to develop a SD-transport (SD-player without integrated DAC) for use with all external DACs that support SPDIF.
The unit is based on the existing SD-transport module.
In order to maintain lowest possible jitter at the external DAC, the SD-transport can be slaved with a blank SPDIF stream transmitted from the external DAC. Masterclock can then be located close to the DAC chip. If the SD-transport detects no external clock, it uses the internal clock.
The SD-transport can run on both, small mains adapter or battery.
I am planning to use Toslink for both I2S out and I2S in (slave mode) in order to get perfect galvanic insulation and offer plug and play compatibility with external DACs.
The cheapest version will only have remote control (no keys).
Display is same as on SD-transport, large white LED display with excellent readability with color filters for different display colors.
The SD-transport housing is same quality (aluminum) as the SD-player with integrated TDA1541A-MK3 module.
John, what are your observations of the effect of length of i2s runs on SQ and measurement with your SD transport feeding your own dac? For example, in your ISD, since the transport shares the same chassis as dac, the line is very short. But when you feed the i2s from your SD transport box to your Dac box the i2s line out (from pcb to pcb) must be much longer than 1 foot?
I have a squeezebox unit that is slaved to an external dac which feeds a masterclock back to transport and then resynchronizes the signals just prior to the dac chip. My own experience, being a relative novice, is that it is difficult to keep the i2s cable short as would be preferred. It still sounds very good, a step up from spdif. I've considered implementing LVDS over shielded twisted pair. Did you experiment with LVDS?
sd-player 1541a-mk3
to give a short feedback regarding the john's sd-player:
i have just received the sd-player (mk3). my first impressions are excellent. i never heard such clear, correct and detailed sound with my hifi chain like this. the back ground is very quite and dark and the sound very present with high resolution.
i am comparing this unit with my cd-player ( cdpro2m, dddac 8x1543 directly connected through i2s) which to my ears is very pleasant and musical and outperforms some very expensive high-end cd-players. i have connected the sd-player with a silver wired tvc (silvercore) to my 300b power amps (2x7watt, little ceasar2 , triode dick). my speakers are wide range open baffle with stereo active subs (bastani's prometheus air force mk2, 100db/wm) . the components are supplied by a central main power conditioner (isotek nova).
in this configuration the output of the sd-player (0,7v rms) is more than sufficient to provide a realistic and live sound stage.
i will provide more info as soon as i have tested the unit in more detail.
john, i thank you again very much for this successful project and sharing your know-how with your community. you have developed very new ideas, deployed and enhanced them in practical applications in a very unique way.
kind regards
mamal
to give a short feedback regarding the john's sd-player:
i have just received the sd-player (mk3). my first impressions are excellent. i never heard such clear, correct and detailed sound with my hifi chain like this. the back ground is very quite and dark and the sound very present with high resolution.
i am comparing this unit with my cd-player ( cdpro2m, dddac 8x1543 directly connected through i2s) which to my ears is very pleasant and musical and outperforms some very expensive high-end cd-players. i have connected the sd-player with a silver wired tvc (silvercore) to my 300b power amps (2x7watt, little ceasar2 , triode dick). my speakers are wide range open baffle with stereo active subs (bastani's prometheus air force mk2, 100db/wm) . the components are supplied by a central main power conditioner (isotek nova).
in this configuration the output of the sd-player (0,7v rms) is more than sufficient to provide a realistic and live sound stage.
i will provide more info as soon as i have tested the unit in more detail.
john, i thank you again very much for this successful project and sharing your know-how with your community. you have developed very new ideas, deployed and enhanced them in practical applications in a very unique way.
kind regards
mamal
SD card recorder
Do you guys know any open source or DIY SD card recorder ? If not open source maybe just a cheap one since the ones I found are around $400 😱 ?
Do you guys know any open source or DIY SD card recorder ? If not open source maybe just a cheap one since the ones I found are around $400 😱 ?
You mean something like this?
Edirol R-09HR Portable Recorder - eBay (item 290465531685 end time Aug-29-10 00:07:24 PDT)
Hi riotubes,
In general, every buffer, receiver and interlink adds jitter and interference. One has to take into account that signals that passed these devices are degraded to some extent. These signals are therefore not ideally suited to directly drive a DAC while attempting to maintain lowest possible jitter and interference levels.
Other problems are ground loops and EMI.
If you must use longer I2S interlinks, I suggest using RS422 transceivers like DM8922 for example. I tested LVDS some years ago, but experienced data corruption and problems with EMI whith interlinks longer than 1 meter.
In general, every buffer, receiver and interlink adds jitter and interference. One has to take into account that signals that passed these devices are degraded to some extent. These signals are therefore not ideally suited to directly drive a DAC while attempting to maintain lowest possible jitter and interference levels.
Other problems are ground loops and EMI.
If you must use longer I2S interlinks, I suggest using RS422 transceivers like DM8922 for example. I tested LVDS some years ago, but experienced data corruption and problems with EMI whith interlinks longer than 1 meter.
Hi fff0,
The SD-transport was designed for 44.1/16 playback only. 32 bits / frame was used to achieve best performance by creating a continuous I2S data stream without zeros inserted between samples. When using 64 bits / frame, zeros need to be added for unused bits. These in turn create a "pulsed" I2S data stream that results in subtle but audible sound quality degradation as I2S interference always finds it's way to the DAC chip output (crosstalk).
Technically there are advantages because we effectively doubled usable ping-pong RAM buffer size in the controller. When inserting zeros between the samples these would take up half of the ping-pong buffer size. The buffer size is important for maintaining data flow with given SD(HC) card access time. This ping-pong RAM buffer is part of the DCI hardware that provides I2S stream. It is possible to reserve more (software) RAM buffer capacity, but this would be much slower (problems with SD(HC) card access time) and puts a larger load on the processor (higher interference).
The SD-transport was designed for 44.1/16 playback only. 32 bits / frame was used to achieve best performance by creating a continuous I2S data stream without zeros inserted between samples. When using 64 bits / frame, zeros need to be added for unused bits. These in turn create a "pulsed" I2S data stream that results in subtle but audible sound quality degradation as I2S interference always finds it's way to the DAC chip output (crosstalk).
Technically there are advantages because we effectively doubled usable ping-pong RAM buffer size in the controller. When inserting zeros between the samples these would take up half of the ping-pong buffer size. The buffer size is important for maintaining data flow with given SD(HC) card access time. This ping-pong RAM buffer is part of the DCI hardware that provides I2S stream. It is possible to reserve more (software) RAM buffer capacity, but this would be much slower (problems with SD(HC) card access time) and puts a larger load on the processor (higher interference).
Yeah, something like that but cheaper. I don't need it to have mics, actually I don't even need it to have ADCs or DACs (but would be nice), only need it to record files on an SD card (in FAT32 format for example).
Just bumped into this thread. This is very interesting. I have yet to read the entire thread, but may I suggest an A-B feature with the remote? This is very useful for practicing musicians who want to repeat a section of a track and play along for practice.
My apologies if this has already been discussed.
--Gobble
correct me if i m wrong, but as far as i know, ECdesigns tends to put a tag on their products once they are in near release phase. also usually modules or complete units are available.
one feature i d like in such a player would be an equalizer, because perfectly linear sound reproducing devices are pretty rare. despite being a daunting project in appearance (probably also in practice), one can only dream about such a feature.
one feature i d like in such a player would be an equalizer, because perfectly linear sound reproducing devices are pretty rare. despite being a daunting project in appearance (probably also in practice), one can only dream about such a feature.
Hello ecs
Does it mean that in general my home wireless router and laptop will degrade SQ anywhere in the house or are you saying implementing wireless feature when incorporated into the board will reduce EM induced degradation of SQ?
Thanks
--G
A$1100 - Actually, for the quality and potential, it's quite reasonable, even cheap.
Compare some of the other top level computer source dacs like the "Wavelength" dac, the "Aire unit, etc., etc. - different systems and different dac chips, etc but it'll give some idea of value for money.
As an example of build quality, have a good look at those non-inductive, non-capacitive hand made Isotan resistors - this is about as good as it gets!
Compare some of the other top level computer source dacs like the "Wavelength" dac, the "Aire unit, etc., etc. - different systems and different dac chips, etc but it'll give some idea of value for money.
As an example of build quality, have a good look at those non-inductive, non-capacitive hand made Isotan resistors - this is about as good as it gets!
- Status
- Not open for further replies.