![]() ![]() |
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
213.7.111.221
In Reply to: RE: Not hard at all posted by Sunya on November 04, 2008 at 17:30:07
Yes, theory says one thing. In practice, though, I have not found clocking to be particularly effective in raising the quality of sound over relocked spdif/aes. The problem seems to be that clocking is just as susceptible to cable and connector type as other interfaces (so is I2S). External clocking produces a different sound; not necessarilly better. Many clocks that claim to be superior are actually not that great; hence these ultra expensive ones which I don't want to have to pay for.
I am talking about using 6 or seven clocks and clocking schemes involving dCS, Apogee, Lynx and others. In fact, clocking the Lynx AES 16 is nothing but trouble.
Follow Ups:
You say that clocking the Lynx16 is nothing but trouble. I have a customer that has had no problems and then another that cannot get it to work, so I have his setup here right now for debug, so now I have to deal with this.
Is there some trick to the LynxAES16 and using word-clock?
I know the word-clock signal is parallel terminated to 75 ohms and many drivers dont handle this well. The signal looks fine on my gear though.
Steve N.
I put it down to the synchro lock feature that seems to hunt from lock to unlock. There is probably an issue with the software(?) or haradware(?)which reports the clock rate at 600-800 ppm out. However, all my dacs lock on which would seem to indicate an issue with the card
You should try on the Lynx Support Forum and get some info from the Lynx engineers.
Lynx support is first rate. When you CALL them.
I'm not talking about using an external clock box like the ones from Esoteric, dCS, Antelope etc. Those are needed in the studios where you have to synchronize multiple devices to a clock reference. When you have only a transport (or a soundcard) and a DAC with Word Clock I/O you don't need an external clock because the idea is the DAC to be controlled by its own internal clock not to receive the clock from another device; so when you slave the transport directly to the DAC it doesn't even matter if the clock signal that reaches the transport is not very accurate because that clock won't be used by the DAC in the conversion process, it's used only by the transport to send the bits to the DAC, while the conversion process uses the clock provided by the internal oscillator in the DAC.
No, in order for the DAC not to care about the transport clock, it must send a word-clock or master-clock to the transport.
Upsampling using ASRC in the DAC does not count. This only reduces jitter a little.
The word-clock will enable the jitter from the transport to be ignored by the DAC.
Steve N.
"No, in order for the DAC not to care about the transport clock, it must send a word-clock or master-clock to the transport."
Well, that's what I said; fmak referred to the use of an external clock generating box, and I said that if the DAC and the transport are equipped with Word Clock I/O, then the better option is to slave directly the transport to the DAC so that the DAC gets the clock only from its internal oscillator, and not to slave BOTH the transport and the DAC to a clock generating box.
"
Actually using an external reclocker as the master can be pretty close to putting the same clock inside the DAC, but depends on the implementation. If the interface is I2S, it's really no different than having the same thing inside the DAC.
11.2896 and 12.288MHz are technically not word-clocks, they are master clocks. I used to mod the Sonos, Squeezebox3 and Duet to have a 11.28986MHz master clock input, but now Rick Cullen does this for me. I dont have the bandwidth to do these mods and so he has picked it up for me. He can do this for you.
Steve N.
And I am saying that such schemes as well as external clock box don't always work and don't necessarilly sound good. Try slaving a Lynx AES16 or a RME 96PAD sound card, listen and you will know what I mean. Don't work well sonically at all.
The UA 2192 dac is supposed top have an excellent clock, but this actually doesn't sound as good as relocking with an Apogee Big Ben.
I know, Lynx claim their own clock has lower jitter than the big Ben. UA claims fantastic things for their clock as well. But this does nbot necessarilly translate into better audio!
The whole thing is right opaque and unless there we do 64 bit FFT on everything, it is difficult to identify best practice.
"Try slaving a Lynx AES16 or a RME 96PAD sound card, listen and you will know what I mean. Don't work well sonically at all."
I have customers using the LynxAES16 with the Pace-Car with excellent results, once they get it working. The final result will depend entirely on how well the master clock is implemented and how low the jitter is.
I looked at the oscillator on the Lynx. Nothing special. $2-5 monolithic.
"The UA 2192 dac is supposed top have an excellent clock, but this actually doesn't sound as good as relocking with an Apogee Big Ben."
All this proves is that you cannot believe what the marketing says. The clocks/implementations are different. It does not prove that word-clock systems dont work. They are definitely superior when done correctly.
Steve N.
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: