I hope Steve Nugent of Empirical Audio reads this so he can give you an expert answer.
As far as my own two ears are concerned, I feel I can put your "fundamental doubts" at ease. Even with a modest USB to SPDIF converter like the TRENDS, the sound holds its own with very much more expensive CDT/DAC combinations and using Steve's SPOILER with PACE CAR reclocker you get a practically jitter free signal, the sound of which easily surpasses both the Zanden Combo as well as the DCS stack in my rig in all the important parameters we audiophiles love. |
USB has no clock - it is an asynchronous protocol. If you use USB then you need to makes sure it handles 24 bits and the audio formats you need - that's all.
Jitter
- if you use USB then it all comes down to the clock in the DAC. (and these are all getting pretty good these days)
- if you use a toslink or SPDIF to feed to a DAC then you will undoubtedly have some jitter as most PC's or Imac devices have jitter and an "interface" tends to create jitter. In this case it boils down to the re-clocking algorithm's in the DAC and it may be important to choose the DAC accordingly. If you have a preferred DAC and it is not well regarded for excellent jitter immunity then a "pace car" would be anoher way to go.
As Detlof says - there is no reason you won;t be able to get excellent sound PROVIDED you get bit transparent data to the DAC (watch out for pitfalls in Digital volume controls, equalizers and just general software bugs...for example some verisons of iTunes are good if you know the proper settings and some versions are actually flawed.) |
Thanks Shadorne and Detlof,
I already use a Reimyo DAP777 as my DAC.
So if the lossless file is going to be Clocked by either the DAC or by the Clock of the USB to SPDIF converter, it becomes very important that the clock input to the DAC is excellent. which could either be via the USB to SPDIF converter (now i undersand the impoertance to the I2S connection) OR via any external reclocker.
I guess the former would always be more preferable as the chain would be shorter. (?)
Now I do have a Trends converter. I have not really tried out the external battery option yet but it does tend to reduce the volume of output (net gain is lower ?) and the treble is not as detailed as my transport.
I guess that must be the result of the poor clock in it. I do not see any issues with the soundstage though..both the breadth and the depth are quite there...it is the tonality and the harmonics which seem to suffer..
That may be due to Jitter ?. i will also try out the old Monarchy DIP which has been out of the chain for quite some time ! |
"My Understanding is that in case of a HDD based transport, the File is converted into an Async format (Lossless) . This is then played via a PC/Mac and when given out as digital out, the clock that is synched to is the machines own clock (Am I right ?)"
The output from the PC, whether it is USB, Firewire or S/PDIF from a soundcard or Mac has the clock embedded. The clock is generated by the computer clock or by a local clock on the sound card.
The only time that the soundcard clock frequency can be influenced is if it has a word-clock input that synchronizes the soundcard clock. This does not reduce jitter however.
Lossless format is optional. There are many formats that can be stored on the computer hard drive or flash drive. They are all converted to the correct format for transmission on the interface, S/PDIF format for this interface, USB format for this interface etc.. The playback software, such as iTunes or Foobar does this transparently. If you have .wav, AIFF and FLAC files of the same track on the disc and you play them one after another, they will all be converted to the same identical data and format for transmission or transport.
The transport formats are different than the stored formats. Transmission of digital data is specific to each interface, USB, Firewire or S/PDIF. Once these are received, they are all eventually converted to either S/PDIF and then I2S or directly to I2S bus.
a) does this impact jitter of the Lossless file in anyway ? also what would the difference between an I2S and an USB interface be in this case as the clock is not really the original clock ?
Jitter is independent usually of the format that the data is stored.
As for the transport format, such as USB, the clock is embedded in the data and must be recovered at the receiving device if it uses Synchronous Adaptive mode. This usually requires a PLL.
I2S is not a native interface for a PC or Mac, so it must be generated from another interface, such as USB, Firewire or S/PDIF. I2S is the native interface for the D/A chip, so all interfaces must end-up converted to I2S.
I2S is not the original clock in the PC, but is synchronous to the original clock.
b) Can the original information without any timing errors be reconstructed from this using an external reclocker like the empirical audio device OR Monarchy ?
Reclockers like the Pace-Car 2 can generate a totally new clock which is synchronous or tracking to the original clock, but with lower jitter.
The original information is only data, not timing. The timing is only implied by the standard frequency that is used at recording time, when the analog data was converted to digital. If the A/D clock had jitter, then the record timing will be innacurate. This cannot be fixed once the data is stored as a digital recording. If the D/A clock has jitter, then the playback timing will be innacurate. This jitter can be minimized with reclockers, upsamplers etc..
c) If the clock is not present will an external DAC just assume the input to be as per its own clock. (If the rip were done by CDROM using the same clock freq as a DAc give any added benefit)
DAC's dont have clocks in general. The only clocks in typical DAC's are for upsampling. DAC's rely on the clock embedded in the incoming datastream, whether it is S/PDIF, AES, Toslink. DAC's recover the clock(s) using hardware. If the interface to the DAC is I2S, then the clocks are discrete so they drive the D/A directly without needing clock recovery.
Ripping has nothing to do with the timing accuracy of a data file. It is simply data. There is data and then there is the timing of when the data is presented to the D/A chip. This timing is not stored on the disk. Only the data is stored on the disk. The timing is recreated at playback time. No relationship to the music timing or beat.
Steve N.
Empirical Audio |
"Shadorne
USB has no clock - it is an asynchronous protocol."
Actually, this depends on the USB protocol. All USB converters use Synchronous Adaptive mode, which uses the embedded clock in the data stream from the USB cable. It relies on the clock at the computer.
Steve N.
Empirical Audio |
" if you use USB then it all comes down to the clock in the DAC."
Some DAC's have upsampling clocks in them, but many have no clock at all. NOS DAC's have no clock.
There are a handfull of very expensive DAC's that generate a local clock and allow you to use this, but only if the source has a word-clock input and can be synchronized to the local DAC clock using a word-clock cable.
Steve N.
Empirical Audio |
Steve,
thanks a lot for that very informative post. Ill need to read it a couple of time more to get it all but I think the core of the issue has been very well explained.
It nice to know that the clock can be recovered and corrected as long as the information is still in the digital domain, irrespective of the format.
Thank you for that. |
Arj,
referencing your original question about I2S, if you have the patience to wait a few months, I think we will start seeing more products trying to use a native I2S interface. PS Audio's new Transport and DAC will be making an I2S connection using HDMI plugs/cables. My hope is that others hop on the bandwagon and begin using HDMI to transmit in native I2S format. Since HDMI cables and plugs are readily available for other purposes, the market barriers to entry are significantly lower for this application.
This would represent a major technology upgrade to one of the weakest parts of PC and digital audio. I have a hard time imagining everyone NOT jumping on this once industry heavies like PS Audio take the lead. I'm also betting (hoping?) custom shops like Steve at Emperical will be able to modify a SqueezeBox or Sonos with an HDMI I2S connection while we wait for manufacturers to ante up.
If the industry could standardize on HDMI components to transmit native I2S, we could kill off the crappy optical and SPDIF connections we use now and virtually eliminate the need for expensive re-clockers (sorry about that part, Steve).
My $.02. In a horrible economy, people aren't going to plunk down big money for something unless it makes a big difference for them. I think this could be it. |
I use Winamp (on WinXP, using ASIO4ALL) to stream from my Sony laptop's toslink output into a plastic toslink cable to a Behringer SRC2496 DAC which then outputs to my system's preamp. I set the Behringer to use its internal clock. Behringer claims the SRC2496 has a "High-precision quartz clock generator [that] removes jitter and corrects off-tune, incorrect sample rates".
My question to the DAC experts here: Is there anything glaringly wrong with how I've set this up? Are there any easy improvements to be made? |
Audioengr,
Can you explain to me how re-clocking is done in an accurate manner?
I understand the concept of "garbage-in, garbage-out" in most information systems meaning that once information is lost or corrupted, it cannot in general be restored back to its initial correct state. It can be massaged perhaps to be better than it might be otherwise, but it will never be the same as it was before the corruption occurred in most cases.
So in the case of jitter, once the clocking of the data is hosed, how practically does re-clocking it make it right again or at least better. What algorithm is used? Is it that the correct clocking is just implicit in the sample rate of the bitstream assuming all the original bits are transmitted? If so, why bother clocking data in these crazy digital audio systems in the first place?
Thanks for any light you can help shed for me on this area that I continue to struggle with understanding clearly. |
Arj wrote:
"If the industry could standardize on HDMI components to transmit native I2S, we could kill off the crappy optical and SPDIF connections we use now and virtually eliminate the need for expensive re-clockers (sorry about that part, Steve)."
I2S alone is not sufficient. First you must have a low-jitter signal. If there is already a lot of jitter, changing the bus to I2S will not fix this. It will still have the same jitter. Reclockers are still needed.
Steve N.
Empirical Audio |
Mapman wrote:
"So in the case of jitter, once the clocking of the data is hosed, how practically does re-clocking it make it right again or at least better. What algorithm is used? Is it that the correct clocking is just implicit in the sample rate of the bitstream assuming all the original bits are transmitted? If so, why bother clocking data in these crazy digital audio systems in the first place?"
The data samples themselves have implicit in them the rate at which the recording samples were taken at record time. This is the standard, a perfect 44.1K samples per second for CD data. The reality is that the sample-rate at record time has jitter too, so it is not a perfect 44.1kHz. Recording studio equipment varies in quality and some A/D clocks are better than others. These sample inaccuracies at record time cannot be corrected. The samples are the samples, that's all you have.
The sample-rate inaccuracies at playback time on the other hand can be minimized. The sample-rate clock is part of the datastream only when the data is being transferred on playback, not when it is stored in RAM or on hard disk. It is the rate at which the sample data is transferred from one point to another, like from a Squeezebox to a DAC or from a Macbook Toslink to a DAC. Each tick of the clock transfers another bit from point A to point B. Without this clock, there would be no playback. The rate is set by the "source" device internal clock, such as the clock inside the Macbook or the clock inside the Squeezebox.
Reclockers goal is to throw away the incoming clock and totally replace it with a local oscillator at the same frequency. The problem is that frequency of the local clock will never be exactly the same as the frequency coming in unless the source clock is generated as a result of the reclocker local clock. This case is precisely what happens when you connect a word-clock cable from a reclocker to a Lynx Card for instance. The Lynx card adjusts its master clock to match the average frequency of the word-clock from the reclocker. Then, the average rate of the data from the source matches the average rate of data transfer of the reclocker output. If these match, then there is no data overrun, no lost bits, no drop-outs. I say "average data rate" because the actual data coming out of the reclocker does not match the incoming rate from clock to clock, only over a large number of clocks. This is what allows the reclocker to output a clock with lower jitter. The time interval between ticks of the reclocker output clock is more consistent than the time interval between ticks of the incoming stream clock. More consistent time interval equals lower jitter. Same thing.
Why reclock at all? Because jitter at the clocks of the D/A converter causes modulation of output analog signal from the D/A converter. This is distortion. This modulation is a function of both the magnitude of the jitter and the spectra of the jitter. This is one of the things that makes digital audio sound "digital" and not analog, along with sample rates that are not high enough.
The evidence of this is really obvious when you compare several DAC's to one another. With a high-jitter input signal, they all tend to sound radically different. With a low-jitter digital input signal, they all start sound very similar. Each DAC behaves a bit differently in the face of jitter, the simplest ones tending to sound the worst with high-jitter input and the best with low-jitter input.
Steve N.
Empirical Audio |
Steve N.,
That makes sense. Thanks so much for the detailed explanation. |
Damn, Steve, I'm dizzy reading all that. Great info. |
