Jitter standards

[David Grant]

Is there some reason why jitter should typically be higher for ADAT than for
SPDIF? Wavefront Semi's opto ADAT receiver spec states 1.5ns which is quite
a lot higher than typical SPDIF receiver ICs I've been looking at.

Just curious.



--
Posted via a free Usenet account from http://www.teranews.com

[Mike Rivers]

David Grant wrote:
> Is there some reason why jitter should typically be higher for ADAT than for
> SPDIF?

Signal transfer through copper wire is more predictable than a signal
that bounces around between the walls of a piece of cheap plastic pipe.


Coax S/PDIF potenitally has less jitter than optical S/PDIF for the
same reason.

[David Grant]

"Mike Rivers" > wrote in message
oups.com...
>
> David Grant wrote:
>> Is there some reason why jitter should typically be higher for ADAT than
>> for
>> SPDIF?
>
> Signal transfer through copper wire is more predictable than a signal
> that bounces around between the walls of a piece of cheap plastic pipe.
>
>
> Coax S/PDIF potenitally has less jitter than optical S/PDIF for the
> same reason.
>

Understand, but not sure how this makes it into the spec for an IC. They
shouldn't be taking the interface into account really, should they? And if
they are they'd have to state the length of optical cable used as that is a
big factor.



--
Posted via a free Usenet account from http://www.teranews.com

[Romeo Rondeau]

"David Grant" > wrote in message
...
> Is there some reason why jitter should typically be higher for ADAT than
> for SPDIF? Wavefront Semi's opto ADAT receiver spec states 1.5ns which is
> quite a lot higher than typical SPDIF receiver ICs I've been looking at.
>
> Just curious.

More data transfer? Is is really typically higher, or is it maybe just that
particular IC?

[Mike Rivers]

David Grant wrote:

> Understand, but not sure how this makes it into the spec for an IC. They
> shouldn't be taking the interface into account really, should they? And if
> they are they'd have to state the length of optical cable used as that is a
> big factor.

Why not call Wavefront and ask them? Get back to us when you have the
explanation.

[Scott Dorsey]

David Grant > wrote:
>Is there some reason why jitter should typically be higher for ADAT than for
>SPDIF? Wavefront Semi's opto ADAT receiver spec states 1.5ns which is quite
>a lot higher than typical SPDIF receiver ICs I've been looking at.

The lightpipe stuff, whether used for ADAT or S-PDIF is pretty marginal
as far as jitter goes. So it is a good idea to have a receiver that can
deal with a lot of phase noise.

I'd like to see S-PDIF receivers that can deal with huge amounts of phase
noise too. But most of the folks who are doing long runs are using copper,
with much less of a jitter problem, so the need for something that can lock
up to messy signals isn't as great.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

David Grant > wrote:
>
>Understand, but not sure how this makes it into the spec for an IC. They
>shouldn't be taking the interface into account really, should they? And if
>they are they'd have to state the length of optical cable used as that is a
>big factor.

They should. BECAUSE the interface that the chip is going to be used with
has a lot of phase noise, THEREFORE the chip should be designed to lock up
to signals with a lot of phase noise.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arny Krueger]

"David Grant" > wrote in message


> Is there some reason why jitter should typically be
> higher for ADAT than for SPDIF? Wavefront Semi's opto
> ADAT receiver spec states 1.5ns which is quite a lot
> higher than typical SPDIF receiver ICs I've been looking
> at.

> Just curious.

More to the point - why worry about jitter during a digital->digital
transfer where the ultimate target is almost always a storage device? As
long as there are no data errors, the storage device acts like a giant
de-jitter buffer, and that is that!

[Scott Dorsey]

Arny Krueger > wrote:
>"David Grant" > wrote in message

>
>> Is there some reason why jitter should typically be
>> higher for ADAT than for SPDIF? Wavefront Semi's opto
>> ADAT receiver spec states 1.5ns which is quite a lot
>> higher than typical SPDIF receiver ICs I've been looking
>> at.
>
>> Just curious.
>
>More to the point - why worry about jitter during a digital->digital
>transfer where the ultimate target is almost always a storage device? As
>long as there are no data errors, the storage device acts like a giant
>de-jitter buffer, and that is that!

Because it is VERY easy to run lightpipe fairly short distances and get
so much jitter that the receiver produces errors or will not lock up.
You cannot run fifty foot lightpipe cables with any degree of reliability
into most receivers, because the jitter gets so bad the receiver cannot
extract a clock.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Romeo Rondeau]

> Because it is VERY easy to run lightpipe fairly short distances and get
> so much jitter that the receiver produces errors or will not lock up.
> You cannot run fifty foot lightpipe cables with any degree of reliability
> into most receivers, because the jitter gets so bad the receiver cannot
> extract a clock.

50 foot is way beyond what lightpipe is capable of anyway.

[Scott Dorsey]

Romeo Rondeau > wrote:
>> Because it is VERY easy to run lightpipe fairly short distances and get
>> so much jitter that the receiver produces errors or will not lock up.
>> You cannot run fifty foot lightpipe cables with any degree of reliability
>> into most receivers, because the jitter gets so bad the receiver cannot
>> extract a clock.
>
>50 foot is way beyond what lightpipe is capable of anyway.

Right, because of the jitter issues. This is bad, since 50 feet is not
a very long run at all.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[David Grant]

>
> More to the point - why worry about jitter during a digital->digital
> transfer where the ultimate target is almost always a storage device? As
> long as there are no data errors, the storage device acts like a giant
> de-jitter buffer, and that is that!

So audio is rarely monitored live through lightpipe ADAT? Is there typically
a greater latency with lightpipe monitoring due to de-jitter buffering on
the receiver end?



--
Posted via a free Usenet account from http://www.teranews.com

[Arny Krueger]

"Scott Dorsey" > wrote in message

> Romeo Rondeau > wrote:

>>> Because it is VERY easy to run lightpipe fairly short
>>> distances and get so much jitter that the receiver
>>> produces errors or will not lock up.

I haven't had any problems with 3' and 12' runs, using Behringer ADA8000s,
which are supposed to be susceptible to this sort of thing.

>>> You cannot run
>>> fifty foot lightpipe cables with any degree of
>>> reliability into most receivers, because the jitter
>>> gets so bad the receiver cannot extract a clock.

I'm under the impression that 10 meters is the usual limit.

>> 50 foot is way beyond what lightpipe is capable of
>> anyway.

> Right, because of the jitter issues. This is bad, since
> 50 feet is not a very long run at all.

I'm not sure its the jitter per se, but the attenuation. Of course a weak
signal is more susceptible to jitter.

[Scott Dorsey]

Arny Krueger > wrote:
>"Scott Dorsey" > wrote in message

>> Romeo Rondeau > wrote:
>
>>>> Because it is VERY easy to run lightpipe fairly short
>>>> distances and get so much jitter that the receiver
>>>> produces errors or will not lock up.
>
>I haven't had any problems with 3' and 12' runs, using Behringer ADA8000s,
>which are supposed to be susceptible to this sort of thing.

12' is just BARELY enough length to get from middle of one rack down to
the floor and up to the middle of the adjacent rack. This is a VERY SHORT
distance.

>>>> You cannot run
>>>> fifty foot lightpipe cables with any degree of
>>>> reliability into most receivers, because the jitter
>>>> gets so bad the receiver cannot extract a clock.
>
>I'm under the impression that 10 meters is the usual limit.

That's about right, and with some systems, 10 meters is marginal. I have
seen folks run 15 meters but being very careful not to bend the cable much
and mounting the cable down so it's never moved. I would consider that
unacceptable, personally.

>>> 50 foot is way beyond what lightpipe is capable of
>>> anyway.
>
>> Right, because of the jitter issues. This is bad, since
>> 50 feet is not a very long run at all.
>
>I'm not sure its the jitter per se, but the attenuation. Of course a weak
>signal is more susceptible to jitter.

The attenuation is also a big issue, yes. But for a really interesting
time, look at the signal coming off the TOSLINK receiver and just see how
smeary it is. You can't just crank the gain up and get away with a longer
cable.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Romeo Rondeau]

>> More to the point - why worry about jitter during a digital->digital
>> transfer where the ultimate target is almost always a storage device? As
>> long as there are no data errors, the storage device acts like a giant
>> de-jitter buffer, and that is that!
>
> So audio is rarely monitored live through lightpipe ADAT? Is there
> typically a greater latency with lightpipe monitoring due to de-jitter
> buffering on the receiver end?

Nobody said it was rarely monitored through. You would never notice
"de-jitter" buffering.

[Les Cargill]

Arny Krueger wrote:

> "David Grant" > wrote in message
>
>
>
>>Is there some reason why jitter should typically be
>>higher for ADAT than for SPDIF? Wavefront Semi's opto
>>ADAT receiver spec states 1.5ns which is quite a lot
>>higher than typical SPDIF receiver ICs I've been looking
>>at.
>
>
>>Just curious.
>
>
> More to the point - why worry about jitter during a digital->digital
> transfer where the ultimate target is almost always a storage device? As
> long as there are no data errors, the storage device acts like a giant
> de-jitter buffer, and that is that!
>
>

I've had Litepipe NICs destroy transfers before. Dunno if it
were drivers, jitter or just having a bad optical hair day.

One time it was because it was a 48kHz source feeding a 44.1
input. Sets my teeth on edge that nothing complained...

--
Les Cargill

[Les Cargill]

David Grant wrote:

>>More to the point - why worry about jitter during a digital->digital
>>transfer where the ultimate target is almost always a storage device? As
>>long as there are no data errors, the storage device acts like a giant
>>de-jitter buffer, and that is that!
>
>
> So audio is rarely monitored live through lightpipe ADAT? Is there typically
> a greater latency with lightpipe monitoring due to de-jitter buffering on
> the receiver end?
>
>
>

No. Latency should be about 1 msec, or something's Wrong.

--
Les Cargill

[Les Cargill]

Romeo Rondeau wrote:

>>>More to the point - why worry about jitter during a digital->digital
>>>transfer where the ultimate target is almost always a storage device? As
>>>long as there are no data errors, the storage device acts like a giant
>>>de-jitter buffer, and that is that!
>>
>>So audio is rarely monitored live through lightpipe ADAT? Is there
>>typically a greater latency with lightpipe monitoring due to de-jitter
>>buffering on the receiver end?
>
>
> Nobody said it was rarely monitored through. You would never notice
> "de-jitter" buffering.
>
>

Whether it's jitter or not, it is possible to get
massive BER on Litepipe, because I've done it.

--
Les Cargill

[Arny Krueger]

"Les Cargill" > wrote in message

> Arny Krueger wrote:
>
>> More to the point - why worry about jitter during a
>> digital->digital transfer where the ultimate target is
>> almost always a storage device? As long as there are no
>> data errors, the storage device acts like a giant
>> de-jitter buffer, and that is that!

> I've had Litepipe NICs destroy transfers before. Dunno if
> it were drivers, jitter or just having a bad optical hair day.

I'd bet on poorly seated terminations on the lightpipe, or a kinked pipe.

> One time it was because it was a 48kHz source feeding a
> 44.1 input. Sets my teeth on edge that nothing complained...

It's nice when you make a mistake and all sorts of red flags go up.

[Plush]

Jitter is never increased in any digital transfer.

The level of jitter in certain program material is defined by the
quality of the a/d when the program is recorded. This "original state"
jitter canot be decreased, so using a very high quality a/d in the
first place is a wise move.

What people are discussing in this topic is a myth.

Instead, it is robust clock transfer that is a problem in long distance
runs.

See Watkinson: The Art of Digital Audio


Scott Dorsey wrote:
> Romeo Rondeau > wrote:
> >> Because it is VERY easy to run lightpipe fairly short distances and get
> >> so much jitter that the receiver produces errors or will not lock up.
> >> You cannot run fifty foot lightpipe cables with any degree of reliability
> >> into most receivers, because the jitter gets so bad the receiver cannot
> >> extract a clock.
> >
> >50 foot is way beyond what lightpipe is capable of anyway.
>
> Right, because of the jitter issues. This is bad, since 50 feet is not
> a very long run at all.
> --scott
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

s
Plush > wrote:
>Jitter is never increased in any digital transfer.
>
>The level of jitter in certain program material is defined by the
>quality of the a/d when the program is recorded. This "original state"
>jitter canot be decreased, so using a very high quality a/d in the
>first place is a wise move.
>
>What people are discussing in this topic is a myth.

What people are talking about is jitter on the transferred clock, NOT
jitter on the reference clock.

It is true that jitter on the reference clock at the A/D converter is
critical to good sound, and it is true that jitter on the clock output
from the A/D converter is only important to the point where it is good
enough that no errors occur.

>Instead, it is robust clock transfer that is a problem in long distance
>runs.

Yes. Jitter on that clock becomes a substantial problem when the signal
is run over crappy lightpipe connections, and the phase error becomes so
high that the receiver can no longer lock up.

>See Watkinson: The Art of Digital Audio

We aren't talking about minor clock problems that may cause sonic degradation.
We're talking about clock problems so bad that the audio breaks up.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Plush]

As I mentioned, there is no possibility of added jitter in any digital
transfer--by AES, SPDIF, TOSLINK or any other interface type.
It sounds like what you're discussing here is a clock problem relating
to locking of the clock or a device locking to a re-clocked stream.

Neither of these topics have anything to do with jitter.

Scott Dorsey wrote:
> What people are talking about is jitter on the transferred clock, NOT
> jitter on the reference clock.
>

[Scott Dorsey]

In article . com>,
Plush > wrote:
>As I mentioned, there is no possibility of added jitter in any digital
>transfer--by AES, SPDIF, TOSLINK or any other interface type.
>It sounds like what you're discussing here is a clock problem relating
>to locking of the clock or a device locking to a re-clocked stream.

Right. Jitter is phase noise on the clock. When you run the clock through
any real transmission medium, you get jitter.

Jitter IS a clock problem. When it gets bad, the clock can no longer lock
and the data can no longer be reclocked.

>Neither of these topics have anything to do with jitter.

So what do you believe jitter is, then, if not phase noise on the clock?

All this stuff was very well defined in the 1960s when Bell Labs was
researching long distance digital transmission systems. This stuff is
not anything new or esoteric. If you want to redefine a term that everyone
in the telecom industry has been using for 40 years, you're going to have
to explain what your new definition means.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."