[aphex944]

"More consistent data transfer." Hahahah..

Seriously though, anyone who truly understands how computers operate, and how information(data) is stored and accessed knows this is entirely rubbish. As far as I'm concerned this completely discredits any observations this guy has ever made if he's convinced of these differences. In this case, listening does not triumph all, some of these observed "audible differences" are physically impossible.

 

[lan]

Quote:

Originally Posted by aphex944 "More consistent data transfer." Hahahah.. Seriously though, anyone who truly understands how computers operate, and how information(data) is stored and accessed knows this is entirely rubbish. As far as I'm concerned this completely discredits any observations this guy has ever made if he's convinced of these differences. In this case, listening does not triumph all, some of these observed "audible differences" are physically impossible.

One does not need to know anything about how something works to observe and use one's senses. Their "conclusions" as well as their listening ability are indeed questionable but I have witnessed somethings on their list and more in my own experiments. I can either have my mind's logic, knowledge, and rationale tell me things or I let my ears. In that regard my ears trump all. It's as easy as, observing do I hear a difference or not? I've tried more things than on lessloss' list. What they're doing is not new in the computer world. To go there, you must have an open mind that this is a system and there will be interaction. In the case of computers, it's nearly irrelevant because if it works, it works. This audio world we're in is a different world and it's not a matter of if you get sound, that's it.

 

[audioengr]

Quote:

Originally Posted by lan Listening trumps all though. The questions are, is all this fancy stuff audible and is the improvement worth the money. Do these companies offer auditions?

Ian's go it right. The issue is whether you can hear it or not. It may be that infinitesimal jitter at certain frequencies or modulation is perfectly audible. Measurements only open the "corellation with what is audible" can of worms....

We offer auditions of demo equipment with a 50% deposit - refundable.

Steve N.

 

[audioengr]

Quote:

Originally Posted by thomaspf Nobody cares about the jitter of a slaved sound card since that clock is not being used for anything. The jitter at the converter chip comes from the local clock. If the bits are the same then there should be no difference, that is the whole idea of a slaved source. If there is a difference the DAC has other problems. Cheers Thomas

This is true, however if the master clock is external to the DAC, the jitter and noise by the time it gets to the DAC chip may be just as bad. Also, these tend to be "word-clocks", not bit-clocks. Most DAC's are affected by the bit-clock jitter.

This is why I2S works so well. It has a bit-clock. It is also possible to generate a master bit-clock for the DAC chip when using USB audio. Almost impossible using a conventional optical drive.

Steve N.

 

[audioengr]

Quote:

Originally Posted by Konig Steve, ive watched the "the girl next door" and i thought the main character's dad resembles you. I wonder if youve taken up a part time job in acting.

I'm actually Richard Gere in disguise.

 

[thomaspf]

Quote:

Originally Posted by audioengr This is true, however if the master clock is external to the DAC, the jitter and noise by the time it gets to the DAC chip may be just as bad. Also, these tend to be "word-clocks", not bit-clocks. Most DAC's are affected by the bit-clock jitter. This is why I2S works so well. It has a bit-clock. It is also possible to generate a master bit-clock for the DAC chip when using USB audio. Almost impossible using a conventional optical drive. Steve N.

Explain to me how the bit jitter affects the conversion if the connection is bit perfect. Here is my understanding.

A DAC does not trigger the conversion on a bit clock but it eventually converts on a word clock. There can be a lot of jitter at the bit level as long as the transmitted bits are the same and the word clock pulses have low jitter.

For chips like the 1704 you don't use the direct I2S signal anyhow since you first synchronously upsample the data stream and then feed that to the actual DAC chip. But even here the converison is triggered by a wclock signal.

The best way to go is still with a local crystal in the DAC that directly drives the word clock. For that you either need to slave the source or you need asynchronous USB/1394.


Cheers

Thomas

P.S. if you can slave the source you can always put some form of secondary PLL into the wclock signal path. The TentLabs XO-DAC looks interesting. Have you played with that.

 

[Silentpug387]

Quote:

Originally Posted by nelamvr6 I don't think we've come even close to plumbing the full depths of "audiophile" gullibility. Check this link if you want proof.

This is incredible. The quote from the short story mixed artistic ambiguity and irrelevance so perfectly. Someone really needs to review this thing lol.


"has no direct or indirect influence on the audio signal"
"The sound will be considerably more musical and live sounding"
"$199"

 

[slwiser]

Steve

This is a great ideal. I had not noticed that you were putting you equipment up for demo even with the deposit. This will let people who are serious actually test your equipment with theirs and ears.

Thanks, but I don't know when I will be again in the market but it is good to know this option will be available for me.

Slwiser

Quote:

Originally Posted by audioengr Ian's go it right. The issue is whether you can hear it or not. It may be that infinitesimal jitter at certain frequencies or modulation is perfectly audible. Measurements only open the "corellation with what is audible" can of worms.... We offer auditions of demo equipment with a 50% deposit - refundable. Steve N.

 

[audioengr]

Quote:

Originally Posted by thomaspf Explain to me how the bit jitter affects the conversion if the connection is bit perfect. Here is my understanding. A DAC does not trigger the conversion on a bit clock but it eventually converts on a word clock. There can be a lot of jitter at the bit level as long as the transmitted bits are the same and the word clock pulses have low jitter. For chips like the 1704 you don't use the direct I2S signal anyhow since you first synchronously upsample the data stream and then feed that to the actual DAC chip. But even here the converison is triggered by a wclock signal. The best way to go is still with a local crystal in the DAC that directly drives the word clock. For that you either need to slave the source or you need asynchronous USB/1394. Cheers Thomas P.S. if you can slave the source you can always put some form of secondary PLL into the wclock signal path. The TentLabs XO-DAC looks interesting. Have you played with that.

I believe most DAC's only use the Sync or L/RCLK signal (which is not a word clock) to align the frames. It is a data signal just like the serial data, not a clock. The bit-clock or SCLK is what actually clocks the entire DAC. It is the synchronous clock. The Master Clock or MCLK is used for other housekeeping I believe, such as digital filtering. MCLK does not even have to be phase-aligned for most DAC chips and other chips dont even use it.

The conversion in a parallel DAC does occur on a word boundary, but this boundary is created internally by using the bit clock.

You are correct about the PCM1704. It uses an upsampler chip first, but the upsampler uses the bit-clock also and I believe is affected by it's jitter to some extent.

Steve N.

 

[thomaspf]

Quote:

Originally Posted by audioengr I believe most DAC's only use the Sync or L/RCLK signal (which is not a word clock) to align the frames. It is a data signal just like the serial data, not a clock. The bit-clock or SCLK is what actually clocks the entire DAC.

Indeed, the LRclock signal is a wordclock signal and the conversion is triggered by it and not by the bitclock. A wordclock is nothing more than a TTL level signal that is at TTL level for 1/(2*Fs) and at 0V for the other half of the clock period.

The LRclock signal is the one you need to get stable. Or in the case of an external filter the wclock input that is driven by the external upsampler.

The bit clock just drives loading the bits into the buffer and it is of course just another data signal like the LRclock or the actual data itself. That said the LRclock and the bit clock need to be frequency locked since the loading of the bits occours at a fixed offset from the LRclok transition.

Cheers

Thomas

Edited to clarify that a LRclock is a word clock!

 

[audioengr]

Quote:

Originally Posted by thomaspf Indeed, the LRclock signal is a wordclock signal and the conversion is triggered by it and not by the bitclock. A wordclock is nothing more than a TTL level signal that is at TTL level for 1/(2*Fs) and at 0V for the other half of the clock period. The LRclock signal is the one you need to get stable. Or in the case of an external filter the wclock input that is driven by the external upsampler. The bit clock just drives loading the bits into the buffer and it is of course just another data signal like the LRclock or the actual data itself. That said the LRclock and the bit clock need to be frequency locked since the loading of the bits occours at a fixed offset from the LRclok transition. Cheers Thomas Edited to clarify that a LRclock is a word clock!

L/RCLK is certainly used to delineate the words, but if it is a true clock, then why is a setup and hold time specified with respect to the bitclk in the DAC datasheets?

Also, why would you have two clocks in a synchronous system unless they are maybe phases of the same clock?

I dont believe that L/RCLK is the one you need to get stable, it's bitclk or SCLK.

Steve N.

 

[thomaspf]

Hi Steve,

could you point me to that data sheet? All I know and have seen is that a certain hold time [or bit clocks]after the LRCLK transition the data is shifted into the shift register of a DAC.

Quote:

Originally Posted by AD1955 In normal operation, there are 64 bit clocks per frame (or 32 per half-frame). When the SPI word length control bits (Bits 2 and 3 in Control Register 0) are set to 24 bits (0:0), the serial port will begin to accept data starting at the eighth bit clock pulse after the LRCLK transition. When the word length control bits are set to 20-bit mode, data is accepted starting at the 12th bit clock position. In 18-bit mode, data is accepted starting at the 14th bit clock position. In 16-bit mode, data is accepted starting at the 16th bit clock position. Note that the AD1955 is capable of a 32 fS BCLK frequency “packed mode” where the MSB is left-justified to an LRCLK transition, and the LSB is right-justified to the next LRCLK transition. LRCLK is high for the left channel, and low for the right channel.

It's not an issue of having 2 clocks. It's an issue of which signal is the relevant one for conversion jitter.

The bit clock and the lrclk need to be synchronous. In normal mode as described above the bclock is 64x lrclk so you can derive the lrclk for the bit clock. However, when you do that you need to do it in a way end to end that keeps the jitter extremely low on the lrclk tansitions on the DAC chip. The bit clock transitions don't really matter. They are used to shift the data in the shift register and what matters there is the timing relationship of the data lines to the transition so you push the valid data.

If you have a DAC that is using a wordclock output you need to basically have frequency multiplier on the receiving end to serialize an S/PDID data stream that is synchronous to the word clock.

Please clear up anything that might be wrong in this description.

Cheers

Thomas

 

[audioengr]

Quote:

Originally Posted by thomaspf Hi Steve, could you point me to that data sheet? All I know and have seen is that a certain hold time [or bit clocks]after the LRCLK transition the data is shifted into the shift register of a DAC. It's not an issue of having 2 clocks. It's an issue of which signal is the relevant one for conversion jitter. The bit clock and the lrclk need to be synchronous. In normal mode as described above the bclock is 64x lrclk so you can derive the lrclk for the bit clock. However, when you do that you need to do it in a way end to end that keeps the jitter extremely low on the lrclk tansitions on the DAC chip. The bit clock transitions don't really matter. They are used to shift the data in the shift register and what matters there is the timing relationship of the data lines to the transition so you push the valid data. If you have a DAC that is using a wordclock output you need to basically have frequency multiplier on the receiving end to serialize an S/PDID data stream that is synchronous to the word clock. Please clear up anything that might be wrong in this description. Cheers Thomas

Here is a link to the AD1853 datasheet, a very good DAC chip:

http://www.analog.com/UploadedFiles/...67AD1853_a.pdf

Here is the datasheet for the DF1704 as well:

http://focus.ti.com/lit/ds/symlink/df1704.pdf

They both specify a set-up time for L/RCLK.

It's hard to believe that the SCLK is not used for shifting the words out. This is what happens in most all synchronous systems. The same clock is used throughout the chip.

How long have you been doing digital design BTW?

Steve N.

 

[thomaspf]

Good point. This text in the 1853 spec is pretty clarifying.

Quote:

The serial-to-parallel data transfer to the DAC occurs on the falling edge of WCLK. The change in the output of the DAC occurs at the rising edge of the 2nd BCLK after the falling edge of WCLK.

While the lrclock determines the word boundaries the jitter sensitive conversion is triggered by the rising edge of the 2nd bclk after the wclk signal.

This makes it pretty clear that the bclk is the signal that needs to be low jitter (at least every second clock wtick after the lrclk transition).

Thanks for clarying this for me.

This leaves us with the question whether the bclk output from a USB audio controller has any more or less jitter than what can be recovered via a S/PDIF receiver and a secondary PLL

Cheers

Thomas

P.S.: I am a software kind of guy.

 

[audioengr]

Quote:

Originally Posted by thomaspf Good point. This text in the 1853 spec is pretty clarifying. While the lrclock determines the word boundaries the jitter sensitive conversion is triggered by the rising edge of the 2nd bclk after the wclk signal. This makes it pretty clear that the bclk is the signal that needs to be low jitter (at least every second clock wtick after the lrclk transition). Thanks for clarying this for me. This leaves us with the question whether the bclk output from a USB audio controller has any more or less jitter than what can be recovered via a S/PDIF receiver and a secondary PLL Cheers Thomas P.S.: I am a software kind of guy.

You know quite a bit about hardware for a software kind of guy. I've been doing digital design for about 30 years.

Frankly, this whole "word-clock" mistique is probably based on some older DAC implementations and does not even apply to most modern DAC chips. It depends entirely on the DAC chip as to whether it is helpful or not.

This is why my I2S implementation is so good sounding. The BCLK has very low jitter. S/PDIF implementations are not as good. You can tell the difference after about 10 seconds of listening to music. It's not subtle. Not that my S/PDIF implementations are not good, they also have very low jitter. The I2S is just better.

Steve N.