 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
12.17.229.69
In Reply to: RE: "A soundcard puts the DAC inside the computer" - only if you choose to do so. posted by Charles Hansen on November 03, 2008 at 17:40:00
Hey Charles
What about cards that output I2s? Wouldn't that get around the spdif issue?
I have seen one but for the life of me I can't remember who makes it.
Follow Ups:
I^2S is a lot better than S/PDIF. But sending a clock down a long cable is going to add jitter. You have to have perfect transmitters and receivers, the cable has to have perfect impedance, the connectors need to be perfect. It's much better to put the clock 1" away from the DAC chip and send the signal over on a controlled-impedance trace.
This is what I have been saying to the PC guys; they seem to think software works on its own magically!
That's what I told to the PS Audio folks regarding their new transport and DAC. That they should slave the transport to the DAC and not the DAC to receive the clock from the transport, even if it's through a separate wire. But for this you need Word Clock I/O on the transport and DAC. It seems I couldn't convince them. Maybe it's too difficult to implement Word Clock I/O for all the sampling frequencies, since the PWT will be a universal transport that will read regular CDs as well as hi-res files burned on a data DVD up to 24/192.
It is difficult to implement a word-clock in a source device. There would be a lot more transports with with feature if it was so easy. It must have a PLL that can sense the sample-rate and change this on the fly and then accurately track a much lower frequency clock. This is non-trivial. The DAC word-clock output is the simple part.
Steve N.
> > Maybe it's too difficult to implement Word Clock I/O for all the sampling frequencies < <
We've been building equipment like that for over 10 years. In our DVD players and the C-5xe universal stereo player, the audio clock is the master clock. (There are actually two master clocks -- one for multiples of 44.1 kHz and one for multiples of 48 kHz.) Then the transport is slaved to the audio master clock.
In our equipment, this is done all inside of one box. But you could easily do it with a two-box system also. For evidence of this, look at Stereophile's archives for reviews of the Linn Karik/Numerik and the Wadia 27/270.
I've read that review long time ago. The In Sync part explains quite well the principle. I just wonder why not all the manufacturers of transports and DACs offer Word Clock I/O on their stuff. It would be such a simple solution to overcome the flaws of SPDIF. As I understood it the Linn used a proprietary connection to slave the transport to the DAC and not the standard BNC Word Clock I/O.Another interesting article is the "Bits is Bits?" They show graphically how would be the correct way to connect transports and DACs and how the majority to it, that is using PLLs in their DACs to recover the clock from the SPDIF signal..
Prism DA-2 DAC has for example Word Clock I/O and is able to act as the Master Clock so you can slave the transport to it; it can output 44.1, 48, 88.2 and 96. The thing is you can't find transports with Word Clock inputs that can be slaved. Esoteric has them on their transports but you are limited only to 16/44.1. Marantz also has them on their high end models, but you face the same limitation. I was hoping the guys at PS Audio would do a complete job by offering an universal transport (able to also read hi res files from data DVDs like FLAC and WAV besides CDs) that will also be able to be slaved to a DAC equipped with an Word Clock output. But they argued that their digital outputs have extremely low jitter (1-2ps) and if you use the transport with their DAC through the I2S connection jitter simply won't be an issue.
Edits: 11/05/08
I think the reason why PSAudio did not put a word-clock on their new transport is to accomodate the new reclocker that they have planned that addresses the same market as my Pace-Car reclocker, namely WiFi device market, such as AirPort Express, AppleTV, Sonos, Squeezebox, Duet, etc.. These devices dont come with word-clock inputs (although I do add slave clock inputs to Sonos and SB3), so the only way their reclocker will work with them is to drive the clocks I2S to the DAC. It is this dual-purpose that caused them to make this decision I believe.
Steve N.
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.
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:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
