[maarek99]

Thanks for the info guys. But what about Dolby Digital? I mean, it gets send encoded through the cable and then it gets decoded. There cannot be any bitdifferences because it would really screw the encoding. Its like sending a zip-file, that gets decoded afterwards. So a jitter has no effect on DD only on PCM signals?

 

[gaboo]

Quote:

Originally Posted by maarek99 Thanks for the info guys. But what about Dolby Digital? I mean, it gets send encoded through the cable and then it gets decoded. There cannot be any bitdifferences because it would really screw the encoding. Its like sending a zip-file, that gets decoded afterwards. So a jitter has no effect on DD only on PCM signals?

Jitter on PCM is not due to bit differences! That would be BER (bit error rate). Jitter is the imperfect timing of 1s and 0s, not altering the values. So DD can have jitter.

Also, sorry for hijacking your thread.

 

[jefemeister]

Quote:

Originally Posted by Glassman good solution using existing S/PDIF standard is buffering say half a second and running VCXO oscillator controlled by very long digital PLL, half a second is more than enough to keep track with incomming clock and on the other hand not so disturbing delay..

Sounds familiar

I agree that this is the best way to do it if you can not slave the devices together with a seperate clock line. All you really have to do is make sure the two clocks are the same on the average and then make sure your buffer is big enough to account for it.

 

[thomaspf]

A dejitter buffer that is filled by the unregulated data stream and emptied by a local clock that is slaved to the average incoming signal rate is what most designs are trying to do.

I believe I mentioned here before that Weiss is using a sophisticated version of this approach and has removed the master clock inputs from their latest generation DACs. According to them it brings no benefits any more.

maarek99
The clock at the DAC chips for DD/DTS signal in almost all consumer receivers is still directly slaved of the S/PDIF signal. The fact that you have a decoding step in the middle does not change that. Most designs are fully synchronous.

Cheers

Thomas

 

[Zanth]

I love threads like this

I learn lots from you boys.

Now then, if one wants to construct a FAQ, I'm more than willing to edit it and sticky it. It would be very useful to the membership.

 

[Zurg]

Pioneer has a set of "Elite" components that allows their universal player to send HiRes SACD data over an iLink (aka firewire) to their "Elite" receiver which also has iLink. Clearly this is, so far, a proprietary interface. Their marketing hype claims that this is a jitter free way to send the digital audio data.

Based on the info in this thread, I wonder if this is true. Does anyone here know whether they are using the "standard" firewire audio protocol, (which has jitter), or have they developed their own? Any info would be appreciated.

-Z

 

[thomaspf]

I don't have a Pioneer receiver but my understanding is that they implement both the standard A&M profile of SACD/DVD over 1394 for interoperability as well as a proprietary mode in which the player is slaved of the clock in the receiver that only works with their players.

As far as I know you are susceptible to jitter in the standard A&M profile since it is using an isochronous transport.

Cheers

Thomas