TRANSPORT COMPATIBILITY
P: DAC64 is not compatible with most transports. It does not lock to the
incoming signal. However with a Toslink connection it works fine with all transports I've used so far. With coaxial after a long pause I have to switch it off and on to get it to lock again. Not so with Toslink, which somehow seems to sound better. I understand you
have changed the jitter window from 20nS to 45nS by inserting a reformulated EPROM.
But I have compared both models and the tighter the window the better the sound (provided you have a compatible transport). Why?
Rob answers:
The jitter window was improved by improving the design of the receiver FPGA, making it capable of extracting data with very large jitter.
The jitter window was more than doubled, and I am now close to tolerating
50 per cent min bit cycle time - the theoretical limit. In performing this update, the DAC and filter FPGA programs are identical - only the extraction circuits. So it is difficult to see how this could significantly change the sound. I have not had a lot of experience with different transports, but I know people have had different experiences. The problem is the RF noise injected into the DAC from the transport, this can effect the sound, making it brighter and more up-front with noisy sources.The solution is (as you state)to use the optical which does not suffer from this effect. In normal situations optical generates so much jitter, that this benefit is masked by the degradation of the jitter. But with the RAM buffer, source jitter is eliminated, so you only have benefits in using optical. Trouble is, most audiophiles have such a prejudice against optical, they won't even try it.
The reason I give 1 and 4 seconds is the only time you get that is
guaranteed 8 seconds of silence is when you are changing discs. So you can
have 72 minutes of playing a CD where the pointers are completely separate.
If the clock on the transport is low quality and not accurate, the 1 second
delay can drift to so that there is no delay - then suddenly 8 seconds! So
we give the option for poor accuracy transport clocks. The vast majority of
hi-end transports are accurate enough for 1 second.
P:
1. Suppose you take less than 8 seconds to change the disc...
2. Suppose you leave the disc on repeat...
3. Suppose you use the DAC to convert DAB and listen for more than,say, 72 minutes...
How do you keek the pointers separate in this instance?
Rob answers:
The DAC 64 works by having a RAM FIFO buffer with two pointers - a write pointer, for writing new data into the RAM and a read pointer for reading the data. Now the two pointers are clocked totally independently, they are completely asynchronous. So how do we get the required delay? This is done by detecting 8 seconds of digital silence, when the pointers are both reset. The read pointer is reset to 1 sec or 4 sec delay, depending on the switch setting. As soon as data appears, the pointers are set on their merry independent paths, and remain in this state until 8 seconds of digital silence. The read pointer is clocked by a local master clock crystal - this provides all the clocks for the filter and DAC. Hence source jitter is removed.
P:
Chord has a new dedicated CD transport. Why didn't you make it SACD compatible with an HDMI output so we could finally take advantage of the DAC alleged DSD capability?
Rob answers:
I wanted to use larger tap length WTA filters, as I felt this would
improve the sound. Subsequent experiments confirmed this, and I ended up
using 4096 taps. Designing a DSP core that can do 4096 taps is not a trivial exercise. The DSP cores I design myself at the logic level using schematic capture - its the only way of getting the performance I need. For the CD player there are 3 cores, all running at 101 MHz with up to 80 bit path lengths! So faced with this large amount of work, I did not want to add DSD etc. since it would add too much to the development time. Note that with the DAC 64, and with the CD player, everything starting from data input to output is designed by me at the individual gate level. So there is a lot more work involved in putting a product together - its like building a computer by designing your own microprocessor and writing the operating system too - rather than simply buying an Intel and Windows and assembling it together. Conventional chips are designed for mass market audio, not for high-end.
P: DAC64 is not compatible with most transports. It does not lock to the
incoming signal. However with a Toslink connection it works fine with all transports I've used so far. With coaxial after a long pause I have to switch it off and on to get it to lock again. Not so with Toslink, which somehow seems to sound better. I understand you
have changed the jitter window from 20nS to 45nS by inserting a reformulated EPROM.
But I have compared both models and the tighter the window the better the sound (provided you have a compatible transport). Why?
Rob answers:
The jitter window was improved by improving the design of the receiver FPGA, making it capable of extracting data with very large jitter.
The jitter window was more than doubled, and I am now close to tolerating
50 per cent min bit cycle time - the theoretical limit. In performing this update, the DAC and filter FPGA programs are identical - only the extraction circuits. So it is difficult to see how this could significantly change the sound. I have not had a lot of experience with different transports, but I know people have had different experiences. The problem is the RF noise injected into the DAC from the transport, this can effect the sound, making it brighter and more up-front with noisy sources.The solution is (as you state)to use the optical which does not suffer from this effect. In normal situations optical generates so much jitter, that this benefit is masked by the degradation of the jitter. But with the RAM buffer, source jitter is eliminated, so you only have benefits in using optical. Trouble is, most audiophiles have such a prejudice against optical, they won't even try it.
The reason I give 1 and 4 seconds is the only time you get that is
guaranteed 8 seconds of silence is when you are changing discs. So you can
have 72 minutes of playing a CD where the pointers are completely separate.
If the clock on the transport is low quality and not accurate, the 1 second
delay can drift to so that there is no delay - then suddenly 8 seconds! So
we give the option for poor accuracy transport clocks. The vast majority of
hi-end transports are accurate enough for 1 second.
P:
1. Suppose you take less than 8 seconds to change the disc...
2. Suppose you leave the disc on repeat...
3. Suppose you use the DAC to convert DAB and listen for more than,say, 72 minutes...
How do you keek the pointers separate in this instance?
Rob answers:
The DAC 64 works by having a RAM FIFO buffer with two pointers - a write pointer, for writing new data into the RAM and a read pointer for reading the data. Now the two pointers are clocked totally independently, they are completely asynchronous. So how do we get the required delay? This is done by detecting 8 seconds of digital silence, when the pointers are both reset. The read pointer is reset to 1 sec or 4 sec delay, depending on the switch setting. As soon as data appears, the pointers are set on their merry independent paths, and remain in this state until 8 seconds of digital silence. The read pointer is clocked by a local master clock crystal - this provides all the clocks for the filter and DAC. Hence source jitter is removed.
P:
Chord has a new dedicated CD transport. Why didn't you make it SACD compatible with an HDMI output so we could finally take advantage of the DAC alleged DSD capability?
Rob answers:
I wanted to use larger tap length WTA filters, as I felt this would
improve the sound. Subsequent experiments confirmed this, and I ended up
using 4096 taps. Designing a DSP core that can do 4096 taps is not a trivial exercise. The DSP cores I design myself at the logic level using schematic capture - its the only way of getting the performance I need. For the CD player there are 3 cores, all running at 101 MHz with up to 80 bit path lengths! So faced with this large amount of work, I did not want to add DSD etc. since it would add too much to the development time. Note that with the DAC 64, and with the CD player, everything starting from data input to output is designed by me at the individual gate level. So there is a lot more work involved in putting a product together - its like building a computer by designing your own microprocessor and writing the operating system too - rather than simply buying an Intel and Windows and assembling it together. Conventional chips are designed for mass market audio, not for high-end.