On Thu, 11 Dec 2003 17:56:08 +0000 (UTC)
(Stewart Pinkerton) wrote:

No, you ARE wrong.

No, I'm right - you appear not to understand how domestic digital
audio works.

No, you are WRONG and trying to worm out of it byu changing the argument
and trying to insult my intelligence.

Scenario 2:
The two clocks are not a prefect match, the DAC clock is either
slower or faster than the data sources clock.

in this case, if its faster, it will (periodically) drain all its
buffering, no matter how much there is, and will end up stretching
bits to fill the gap (or playing silence, whatever)

Not relevant to CD, which has a defined 74 minute maximum, and there
do exist fully buffered true reclocking systems such as the Meridian
800 series, which certainly does *not* drop bits.

I didnt specify a CD source, did I?

if its slower, it will, periodically end up with the buffer
over-filling and bits will be lost.

See above.

Yep, adds up to what I said.

jitter is simply noise above, and will average out to nothing.

This however will not help the FM distortion which it causes in the
analogue output of the DAC.................

a few seconds of buffer on any DAC ought to make that 99.999999999%
inaudible.

If it DIDNT cancel out, it'd
effectvely be a frequency drift of the data sources clock, which is
no longer called jitter (duh).

such a 'drift' would imply a loss of data

There will however be *no* loss of data in a domestic audio situation,
so you are flat-out *wrong*.

In the case of CD Im still *correct* its just irrelevant.

in the case of a source capable of more than 74 minutes output, Im 100%
right.

full reclocking systems are as pointless as they are expensive.

--
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.

In article , Ian Molton
wrote:
On Thu, 11 Dec 2003 10:06:03 +0000 (GMT) Jim Lesurf
wrote:

This may be the case if there is no mechanism in the receiver to adjust
its medium/long-term clock frequency towards that of the transmitter.
However the S/PDIF stream has clock info encoded into it.

Indeed. but we were discussing reclocking to a perfect clock, which
means the spdif clock is being replaced by one that is not even locked
to it, which will show the effects described (eventually)

I need to distinguish between two situations:

1) Where the receiver/output clock rate is intended to be essentially the
same as that which we expect to receive. In this case I would call this
process 'reclocking' if a new clock is used at the receiver, rather than
just taking a filtered version of what arrives.

2) Where the receiver deliberately processes the data to a somewhat
different data rate (e.g. converting 44.1kHz data streams to 48kHz). I do
not call this 'reclocking' although I have seen it described as such.

In this thread I am primarily considering (1), not (2). On that basis
reclocking may or may not include a subsystem to adjust the long- or
medium-term frequency of the new clock to be in line with that being
received. Hence reclocking may or may not mean using a receiver clock that
"is not even locked".

In practice, it may well be advisible when converting to also do some form
of locking as well, so that in the example mentioned in (2) you might phase
lock the new 48kHz to the old 44.1kHz.

You always end up needing some amount of data buffering. However if you
have no attempts to lock the clocks over the long term, these buffers may
need to be very large. This may or may not be a 'good idea'. In the end,
with each approach, it comes down to "how well did the
designer/manufacturer impliment their solution as being appropriate for the
intended use?"


Indeed. of course, for the purposes of what I was explaining, its valid
to consider the transmitter clock as perfect and the other running fast
or slow (its the relative difference that matters :-)

I would not view in that way if the practical problem was that the TX clock
shows serious variations which - if allowed to affect the eventual DAC
conversion rates - would cause the output signal patterns to become audibly
phase-rate modulated. This would create a nasty form of intermodulation
distortion with components anharmonic with the music. In this situation it
may make sense to employ a smoother reciever clock, and treat that as being
the one to follow by reclocking the data to it! I would not normally choose
to conside *either* clock as "perfect", just look to see if they were
adequate for their intended purpose.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

In article , Ian Molton
wrote:
On Thu, 11 Dec 2003 10:06:03 +0000 (GMT) Jim Lesurf
wrote:

This may be the case if there is no mechanism in the receiver to adjust
its medium/long-term clock frequency towards that of the transmitter.
However the S/PDIF stream has clock info encoded into it.

Indeed. but we were discussing reclocking to a perfect clock, which
means the spdif clock is being replaced by one that is not even locked
to it, which will show the effects described (eventually)

I need to distinguish between two situations:

1) Where the receiver/output clock rate is intended to be essentially the
same as that which we expect to receive. In this case I would call this
process 'reclocking' if a new clock is used at the receiver, rather than
just taking a filtered version of what arrives.

2) Where the receiver deliberately processes the data to a somewhat
different data rate (e.g. converting 44.1kHz data streams to 48kHz). I do
not call this 'reclocking' although I have seen it described as such.

In this thread I am primarily considering (1), not (2). On that basis
reclocking may or may not include a subsystem to adjust the long- or
medium-term frequency of the new clock to be in line with that being
received. Hence reclocking may or may not mean using a receiver clock that
"is not even locked".

In practice, it may well be advisible when converting to also do some form
of locking as well, so that in the example mentioned in (2) you might phase
lock the new 48kHz to the old 44.1kHz.

You always end up needing some amount of data buffering. However if you
have no attempts to lock the clocks over the long term, these buffers may
need to be very large. This may or may not be a 'good idea'. In the end,
with each approach, it comes down to "how well did the
designer/manufacturer impliment their solution as being appropriate for the
intended use?"


Indeed. of course, for the purposes of what I was explaining, its valid
to consider the transmitter clock as perfect and the other running fast
or slow (its the relative difference that matters :-)

I would not view in that way if the practical problem was that the TX clock
shows serious variations which - if allowed to affect the eventual DAC
conversion rates - would cause the output signal patterns to become audibly
phase-rate modulated. This would create a nasty form of intermodulation
distortion with components anharmonic with the music. In this situation it
may make sense to employ a smoother reciever clock, and treat that as being
the one to follow by reclocking the data to it! I would not normally choose
to conside *either* clock as "perfect", just look to see if they were
adequate for their intended purpose.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

In article , Stewart Pinkerton
wrote:
On Thu, 11 Dec 2003 10:06:03 +0000 (GMT), Jim Lesurf

I don't know if there is any official timescale defined in audio for
the longest term that is 'jitter' beyond which it becomes 'drift' of
'static error'. Hence I'd be inclined to regard these as all facets of
the same problem and treat them accordingly.

Perhaps we could agree that 74 minutes would be a hard limit for jitter
on a CD? :-)


Make it a shade over 80 mins. I have some 80 min CDRs. :-)

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

In article , Stewart Pinkerton
wrote:
On Thu, 11 Dec 2003 10:06:03 +0000 (GMT), Jim Lesurf

I don't know if there is any official timescale defined in audio for
the longest term that is 'jitter' beyond which it becomes 'drift' of
'static error'. Hence I'd be inclined to regard these as all facets of
the same problem and treat them accordingly.

Perhaps we could agree that 74 minutes would be a hard limit for jitter
on a CD? :-)


Make it a shade over 80 mins. I have some 80 min CDRs. :-)

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html