Further to [url=https://www.audio-forums.com/as-rediect/showthread.php?threadid=1005]this thread[/url] I was involved in some heated debate over on the Portuguese hifi forum I'm a member of on the same subject. As it happens, one of the guys there who also runs the website [URL]http://www.hificlube.net/[/URL] (Portuguese) knows Rob Watts and asked him to reply to some questions about the DAC64 set by forum members. Here are some of the questions and answers. The responses on how the buffer works in particular are very interesting... :) [size=3]In relation to transport compatability and jitter:[/size] [b]Q:[/b] [i]The DAC64 is not compatible with many 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 changed the jitter window from 20nS to 45nS in later versions of the DAC64. I have compared both models and the tighter the window the better the sound (provided you have a compatible transport). Why?[/i] [b]A:[/b] 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% 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. [size=3]In relation to the clock and RAM buffer:[/size] [b]Q:[/b] [i]Does DAC64 have its own master clock? What type of clock do you use?[/i] [b]A:[/b] It's a high quality crystal clock with its own buffer and PSU. 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. [b]Q:[/b] [i]If so why does it stop playing whenever you pull the transport plug from the mains, although it sometimes keeps playing when you just open the drawer? Does it rely on the transport clock or not?[/i] [b]A:[/b] When you switch off the transport, digital lock is lost, the outputs are immediately muted via a shorting relay. The transport clock is only used to increment the write pointer into the RAM. All circuitry post RAM is clocked by the DAC clock. [b]Q:[/b] [i]Is the crystal oscillator at the output of the FIFO powered by the same power supply that powers the input of the FIFO?[/i] [b]A:[/b] It uses the PSU for the receiver section. The filter, DAC and analogue all have separate regulated supplies. The input to the filter section is re-synched to remove receiver PSU induced jitter. The PSU is vital, I have always used separate regulators for the clocks. It makes a tremendous difference. [size=3]On digital cables:[/size] [b]Q:[/b] [i]What is the preferred connection of the DAC64, AES/EBU, S/PDIF or Toslink?[/i] [b]A:[/b] Optical. The DAC is still sensitive to the amount of RF noise the transport generates. But when using optical, it is very consistent. Moreover, analogue electronics are also sensitive to the noise the transport generates... [size=3]On the different buffer lenghts:[/size] [b]Q:[/b] [i]What is the difference between the 1s and 4s buffer settings and should there be any audible difference? If not, why the 2 settings?[/i] [b]A:[/b] There is no difference between 1 sec and 4 sec delay once data is running - its exactly the same circuitry doing exactly the same. Using an optical connection, I can't hear a difference between the two settings. 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. My comments: I find what he said about how the clock/buffer works particularly interesting. The fact that the replay (buffer read) clock is [i]totally independent[/i] of the transport does in fact mean that the DAC64 [b]IS[/b] completely immune to jitter coming from the transport. It's impossible for it not to be. However, there are differences between transports caused largely by RF interference. On Saturday I'll have my newly modded Teac T1 (thanks Tone ;) ) hooked up and will play around with optical and other connections to see if this bears out in reality... Another interesting point that comes from this particular method of using the RAM buffer is that if you were using the DAC64 with a DAB radio and left it on all the time there would come a point where you'd get a buffer underrun or overflow and the DAC would have to be reset (by switching it off and on I suspect). So, interesting stuff and my thanks to José Henriques from [URL]http://www.hificlube.net/[/URL] for doing the "interview". Michael.