On Tue, 02 Dec 2003 09:15:24 +0000 (GMT)
Jim Lesurf wrote:

TBH though I recon USB audio would be a decent alternative to all this
unidirectional crap ;-)

I have the feeling that we have had this discussion before, elsewhere...
:-)

Yeah I was thinking that ;-)

One thing we never did resolve though...

Why *is* audio digital transport done in a way that has no feedback?


--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

On Tue, 02 Dec 2003 19:36:53 +0000
Ian Bell wrote:

I am well aware of the term slaved and if you had read my post more closely
you would have realised I was *not* referring to a slaved clock.

You cant feed SPDIF to a non-slaved clock. if you do you will need either short tracks, or massive buffers, and you better *pray* the spdif clock is marginally faster than the free-running one.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

On Tue, 02 Dec 2003 19:36:53 +0000
Ian Bell wrote:

I am well aware of the term slaved and if you had read my post more closely
you would have realised I was *not* referring to a slaved clock.

You cant feed SPDIF to a non-slaved clock. if you do you will need either short tracks, or massive buffers, and you better *pray* the spdif clock is marginally faster than the free-running one.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

On Tue, 02 Dec 2003 09:10:13 +0000 (GMT)
Jim Lesurf wrote:

No idea if any commercial makers use this approach,
though as it is quite complex.

There has got to be a macrocell for it somewhere - just about every 16xxx UART uses a similar tactic...

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

On Tue, 02 Dec 2003 09:10:13 +0000 (GMT)
Jim Lesurf wrote:

No idea if any commercial makers use this approach,
though as it is quite complex.

There has got to be a macrocell for it somewhere - just about every 16xxx UART uses a similar tactic...

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

Ian Molton wrote:

On Tue, 02 Dec 2003 19:36:53 +0000
Ian Bell wrote:

I am well aware of the term slaved and if you had read my post more
closely
you would have realised I was *not* referring to a slaved clock.

You cant feed SPDIF to a non-slaved clock. if you do you will need either
short tracks, or massive buffers, and you better *pray* the spdif clock is
marginally faster than the free-running one.


Actually you can. You just resample. No buffers, no worries about
different clock speeds or source data jitter.

Ian

Ian Molton wrote:

On Tue, 02 Dec 2003 19:36:53 +0000
Ian Bell wrote:

I am well aware of the term slaved and if you had read my post more
closely
you would have realised I was *not* referring to a slaved clock.

You cant feed SPDIF to a non-slaved clock. if you do you will need either
short tracks, or massive buffers, and you better *pray* the spdif clock is
marginally faster than the free-running one.


Actually you can. You just resample. No buffers, no worries about
different clock speeds or source data jitter.

Ian

On Tue, 02 Dec 2003 19:36:53 +0000, Ian Bell
wrote:

Stewart Pinkerton wrote:

On Tue, 02 Dec 2003 10:40:52 +0000, Ian Bell
wrote:

Interesting but completely wrong. The SPDIF first has to be deserialised.
The data has the clock embedded in it which first has to be recovered
before the data can be reclocked and fed into a shift register. A PLL is
used to recover clock and jitter in the SPDIF clock edges will have little
effect on this as the PLL time constant is much longer than the jitter.

Interesting, but completely wrong....................

Any jitter which is present in the incoming datastream will be
attenuated very roughly by the ratio of the main jitter frequency
(commonly 50/100Hz from the power rails) to the PLL time constant
(commonly 10Hz or so to quickly achieve lock) . As you can see, this
isn't much in the way of attenuation! A few of the better DACs
incorporate double PLLs with a secondary loop having a time constant
of a second or so, allowing much better jitter suppression, but the
basic fact remains that jitter in the incoming datastream can only be
*reduced* by the PLL, not eliminated. For that, you require to reclock
the datastream from an independent free-running low-noise clock, and
this is *very* rare.

Rare it may be but that was precisely what i said.

No, you specifically mentioned PLLs, which do *not* reclock the data.

All that happens is that when the bit is sampled (in the middle not the
edge)

Again, completely wrong, as it's the edge transition which is
detected.

Not completely wrong. SPDIF is FM encoded. The clock is encoded as a
transition at the edge of each bit cell. For data, zeros are encoded with
no transition in the centre of the bit cell and one with an extra
transition in the centre of the bit cell.

That's right - note the term *transition*.

the jitter causes the S/N ratio to decrease which means there is an
increasing probability of a wrong bit being detected.

Excuse me? Noise immunity is a *completely* separate issue from jitter
effects, the only common ground being that either can cause bits to be
dropped in extreme cases.

Amplitude and temporal noise (jitter) both affect the probability of the
correct decode of a bit and therefore the S/N ratio. No matter what the
S/N ratio, with gaussian noise, there is always a finite probabilty the bit
will be wrongly decoded

Correct decoding is a separate issue from SNR.

OTOH, I have *never* heard of dropped bits
occurring in a domestic transport/DAC situation.

We are not talking about a transport/DAC situation an SPDIF connection.
SPDIF has *no* error detection and correction so bits *will* be dropped.

Clearly, you are not aware that the connection between a CD transport
and a DAC *is* a S/PDIF link. Please learn the basics. Bits will *not*
be dropped in a typical domestic situation.

Once a word of bits
has been assembled it is then clocked into a DAC in parallel. The only
jitter therefore in the output analogue signal is that introduce by the
internal clock used to clock the word into the DAC. Jitter in the SPDIF
signal is not present in the output.

Absolute garbage, since that 'internal clock' is a PLL which is slaved
to the incoming data stream. You do know what 'slaved' means, I trust?

I am well aware of the term slaved and if you had read my post more closely
you would have realised I was *not* referring to a slaved clock.

What do you think a PLL is? Consider the middle 'L', which stands for
'locked'. Please learn the basics.

As noted, there are a very few DACs to which the above does not apply,
since they genuinely reclock the data, but in the vast majority of
cases, output jitter is directly proportional to input jitter.

This all assumes we are discussing an SPDIF connection to a DAC.

Certainly it does - since this is the only connection where jitter is
relevant.

For an
SPDIF connection to a digital recorder for example any jitter in the SPDIF
signal is irrelevant.

Yes, so why mention jitter in the first place?

As I have said many times in the past, the only
jitter that is important is that introduced by the final DAC and more often
that not that is not connected to an SPDIF stream.

Irrelevant - you are attempting to wriggle your way out of a lost
position.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

On Tue, 02 Dec 2003 19:36:53 +0000, Ian Bell
wrote:

Stewart Pinkerton wrote:

On Tue, 02 Dec 2003 10:40:52 +0000, Ian Bell
wrote:

Interesting but completely wrong. The SPDIF first has to be deserialised.
The data has the clock embedded in it which first has to be recovered
before the data can be reclocked and fed into a shift register. A PLL is
used to recover clock and jitter in the SPDIF clock edges will have little
effect on this as the PLL time constant is much longer than the jitter.

Interesting, but completely wrong....................

Any jitter which is present in the incoming datastream will be
attenuated very roughly by the ratio of the main jitter frequency
(commonly 50/100Hz from the power rails) to the PLL time constant
(commonly 10Hz or so to quickly achieve lock) . As you can see, this
isn't much in the way of attenuation! A few of the better DACs
incorporate double PLLs with a secondary loop having a time constant
of a second or so, allowing much better jitter suppression, but the
basic fact remains that jitter in the incoming datastream can only be
*reduced* by the PLL, not eliminated. For that, you require to reclock
the datastream from an independent free-running low-noise clock, and
this is *very* rare.

Rare it may be but that was precisely what i said.

No, you specifically mentioned PLLs, which do *not* reclock the data.

All that happens is that when the bit is sampled (in the middle not the
edge)

Again, completely wrong, as it's the edge transition which is
detected.

Not completely wrong. SPDIF is FM encoded. The clock is encoded as a
transition at the edge of each bit cell. For data, zeros are encoded with
no transition in the centre of the bit cell and one with an extra
transition in the centre of the bit cell.

That's right - note the term *transition*.

the jitter causes the S/N ratio to decrease which means there is an
increasing probability of a wrong bit being detected.

Excuse me? Noise immunity is a *completely* separate issue from jitter
effects, the only common ground being that either can cause bits to be
dropped in extreme cases.

Amplitude and temporal noise (jitter) both affect the probability of the
correct decode of a bit and therefore the S/N ratio. No matter what the
S/N ratio, with gaussian noise, there is always a finite probabilty the bit
will be wrongly decoded

Correct decoding is a separate issue from SNR.

OTOH, I have *never* heard of dropped bits
occurring in a domestic transport/DAC situation.

We are not talking about a transport/DAC situation an SPDIF connection.
SPDIF has *no* error detection and correction so bits *will* be dropped.

Clearly, you are not aware that the connection between a CD transport
and a DAC *is* a S/PDIF link. Please learn the basics. Bits will *not*
be dropped in a typical domestic situation.

Once a word of bits
has been assembled it is then clocked into a DAC in parallel. The only
jitter therefore in the output analogue signal is that introduce by the
internal clock used to clock the word into the DAC. Jitter in the SPDIF
signal is not present in the output.

Absolute garbage, since that 'internal clock' is a PLL which is slaved
to the incoming data stream. You do know what 'slaved' means, I trust?

I am well aware of the term slaved and if you had read my post more closely
you would have realised I was *not* referring to a slaved clock.

What do you think a PLL is? Consider the middle 'L', which stands for
'locked'. Please learn the basics.

As noted, there are a very few DACs to which the above does not apply,
since they genuinely reclock the data, but in the vast majority of
cases, output jitter is directly proportional to input jitter.

This all assumes we are discussing an SPDIF connection to a DAC.

Certainly it does - since this is the only connection where jitter is
relevant.

For an
SPDIF connection to a digital recorder for example any jitter in the SPDIF
signal is irrelevant.

Yes, so why mention jitter in the first place?

As I have said many times in the past, the only
jitter that is important is that introduced by the final DAC and more often
that not that is not connected to an SPDIF stream.

Irrelevant - you are attempting to wriggle your way out of a lost
position.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

On Tue, 2 Dec 2003 16:29:41 +0000, Ian Molton wrote:

On Tue, 2 Dec 2003 16:18:34 +0000 (UTC)
(Stewart Pinkerton) wrote:

For that, you require to reclock
the datastream from an independent free-running low-noise clock, and
this is *very* rare.

the important detail being that unless you have BI-DIRECTIONAL data transfer you can never reliably re-clock the data, unless you have *gargantuan* buffers (mind you with todays memory prices...)

the point is that in a continuous stream, sooner or later you will have a problem as the free running local DAC wont be running at the same speed as the data stream, so it will, eventually either over- or under- run its data buffer and have either some skipped or lost data, or some 'dodgy' compensation scheme.

whats needed to do it *right* is a data stream that can deliver the data *faster* than its needed, and a source that can pause its transfer.

then the source can transfer at full speed to the DACs buffers, and the DAC can say 'no more please I'm full'.

then as the buffer drains the DAC can request more data.

this utterly eliminates jitter and frankly Im amazed the high-end HiFi audio industry hasnt cottoned on to the idea yet, if not because its audibly better, but because it means they can sell a whole load more interconnects and new DACs etc.

Too late - see the Meridian 800 series.
--

Stewart Pinkerton | Music is Art - Audio is Engineering