[pompon]

I tested my X-Meridian 7.1 against M-Audio 192 and M-Audio was better.
More details, more balanced sound. Was apparent in the first 5 sec ...

I guess it's because they don't use the same clock ... It's all 0 and 1's ... but the timing is done with clock.

 

[linuxworks]

Quote:

Originally Posted by Maniac /img/forum/go_quote.gif #1 Think of digital signal as a water input pipe to your own water tank (reclock) which feeds your home (DAC). If you use a precise clock to reclock the signal, it might be just a little bit faster or slower than the input. And after a while, the small difference will translate into an overflow buffer or an empty buffer with nothing left in it.

I think this is quite wrong. sorry. but there is an asynch nature, its true, but there are also pll's to keep the 'loop' in check. else, as you say, the 2 would diverge and never again meet. that obviously does not happen!

Quote:

#2 Sure, some uses VCXO to adjust the clock's freq to match the input more closely and use buffer's level as an indicator to speed up or slow down the clock. However, VCXO are often extremely jittery, which means the data could be more jittery AFTER the reclocking attempt. (I saw some company that actually did that... who? well, I guess I'll keep quiet on that... )

this is what I'm talking about; correction control. has to be there (I'm pretty sure).

HOW they do it, that's the secret sauce. and so may introduce more errors than they fix. I'd believe that, too

 

[Maniac]

Just some more info, different coupling transformer/cap will also cause different jitter, leading edge deformation and a host of other differences. Other than the clock, there are still a host of other things that can affect the clock and the signal after the clock is embedded into the SPDIF. It just like other part of the audio stuff, part of the system can still affect the entire system, even if it doesn't seem like it will cause a major difference at first sight.

 

[linuxworks]

as for the importance of the source, I'm on the fence about that!

I used to do DAT taping and we tapers would chain dozens of decks together (at shows) and do digital to digital copying (tape trees and so on). the ONLY time digital to digital mattered was at the final d/a stage. this was well known and accepted even 20 yrs ago.

and this is what makes me think there IS enough 'info' (even on badly screwed up spdif waves) that the dac can fix whatever is wrong. the wave would have to jitter SO MUCH that during a whole sample time, the wave would not be where you expected it to be. or the random timing diff would have to intentionally be so bad that the averaging logic could not get a clock from that.

its that experience (doing lots of digital to digital copies) that made me realize it really was only the last stage that mattered. after that, i stopped caring about magic spdif cables and so on. if the bits get there, they get there and the dac has the entire responsibility to make things right. yes, I do put all the responsibility on the dac. he's the ONLY one you have a right to blame (lol).

 

[linuxworks]

Quote:

Originally Posted by Maniac /img/forum/go_quote.gif Just some more info, different coupling transformer/cap will also cause different jitter, leading edge deformation and a host of other differences. Other than the clock, there are still a host of other things that can affect the clock and the signal after the clock is embedded into the SPDIF. It just like other part of the audio stuff, part of the system can still affect the entire system, even if it doesn't seem like it will cause a major difference at first sight.

leading edge issues should not, again, matter. you simply wait for the 'bounce' to stop. it will stop and some 'good section of wave' will still be there. not a problem. only a problem 'visually' when humans look at the waves. dacs, otoh, have been smarter than that. they are not easily fooled by noise on leading or falling parts of the wave. that would be a childish implementation, maybe seen 20 yrs ago, in a dac.

as for passive things affecting jitter, maybe they affect timing but they do NOT add random elements. they always do the same thing. therefore this is not jitter, its easily accounted for (ie, its constant so you can 'work around it' so to speak).

 

[Maniac]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif I think this is quite wrong. sorry. but there is an asynch nature, its true, but there are also pll's to keep the 'loop' in check. else, as you say, the 2 would diverge and never again meet. that obviously does not happen!

Actually the first part is not Async, it does not have any SRC components. Thus the water tank analogy, and the use of a large buffer means that it is not based on SRC due to the fact that SRC type design needs only a few bytes of buffering to get it working. (Or at least that's what ADI's datasheet is leading me to believe. )

I've seen a few examples of the first buffer type reclocking, and it is horrendous, it clicks every few minute and drives user nuts. And with it done right, it will be great, which is what Genesis' Digital Lens is.

 

[Maniac]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif leading edge issues should not, again, matter. you simply wait for the 'bounce' to stop. it will stop and some 'good section of wave' will still be there. not a problem. only a problem 'visually' when humans look at the waves. dacs, otoh, have been smarter than that. they are not easily fooled by noise on leading or falling parts of the wave. that would be a childish implementation, maybe seen 20 yrs ago, in a dac. as for passive things affecting jitter, maybe they affect timing but they do NOT add random elements. they always do the same thing. therefore this is not jitter, its easily accounted for (ie, its constant so you can 'work around it' so to speak).

Actually that's not how chip works, they do not wait for the signal to bounce to top but instead trigger somewhere between the ambiguous state and the definite trigger value.

I still don't see any digital chip that does not have ambiguous state and only trigger at the exact voltage level.


Just checked PCM1794 for the ambiguous state info and here it is.

Between the lowest value of Logic-High of 2V and the highest value of Logic-Low of 0.8V is the ambiguous state, where the chip manufacturer does not guarantee whether if it will trigger high or low. That's where the fun is for jitter processing.