![]() |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
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. No, the PLL is there primarily to *recover* the enbedded clock and and i specifically mentioned a separte clock. Ian 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. |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
. 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. Clearly you are not aware that the link between a CD transport and its DAc is *not* SPDIF. Please learn the real basics. We were not discussing the link between a CD tranport and its DAC but an external SPDIF cable connection. please read the topic for before posting. Ian |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
. 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. Clearly you are not aware that the link between a CD transport and its DAc is *not* SPDIF. Please learn the real basics. We were not discussing the link between a CD tranport and its DAC but an external SPDIF cable connection. please read the topic for before posting. Ian |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
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? If you had bothered to read the original post you would know why. Ian |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
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? If you had bothered to read the original post you would know why. Ian |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
On Tue, 2 Dec 2003 20:00:14 +0000, Ian Molton wrote: 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? Because the people who designed the system never thought that anyone would be dumb enough to split the transport and DAC sections, or if they did, that they wouldn't use a single master clock in the DAC to slave the transport. Then along came the notoriously incompetent so-called 'high end' audio industry......... And on that point I agree 100% Ian |
Co-ax SPDIF digital out
Stewart Pinkerton wrote:
On Tue, 2 Dec 2003 20:00:14 +0000, Ian Molton wrote: 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? Because the people who designed the system never thought that anyone would be dumb enough to split the transport and DAC sections, or if they did, that they wouldn't use a single master clock in the DAC to slave the transport. Then along came the notoriously incompetent so-called 'high end' audio industry......... And on that point I agree 100% Ian |
Co-ax SPDIF digital out
On Wed, 3 Dec 2003 07:55:24 +0000 (UTC)
(Stewart Pinkerton) wrote: No, hes right, you can resample, but you dont preserve the original data, so its a bit pointless. True, but you can also use a data-rate converter, which may be what he meant. I confess that I hadn't even considered the possibility that he was referring to D/A-A/D resampling, which would indeed be terminally brain-dead as a jitter suppression technique! I dont think anyone was talking Analogue here. resampling is merely taking one data stream and producing another, its a very broad term. here its used in the context of altering the bitrate of the stream, using a 'filter'. the filters are actually very simple, but implementing them is non trivial if you wish to avoid artifacts. -- 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. |
Co-ax SPDIF digital out
On Wed, 3 Dec 2003 07:55:24 +0000 (UTC)
(Stewart Pinkerton) wrote: No, hes right, you can resample, but you dont preserve the original data, so its a bit pointless. True, but you can also use a data-rate converter, which may be what he meant. I confess that I hadn't even considered the possibility that he was referring to D/A-A/D resampling, which would indeed be terminally brain-dead as a jitter suppression technique! I dont think anyone was talking Analogue here. resampling is merely taking one data stream and producing another, its a very broad term. here its used in the context of altering the bitrate of the stream, using a 'filter'. the filters are actually very simple, but implementing them is non trivial if you wish to avoid artifacts. -- 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. |
Co-ax SPDIF digital out
On Wed, 3 Dec 2003 07:55:24 +0000 (UTC)
(Stewart Pinkerton) wrote: no, actually hes right, its a one-way connection, no feedback - bits WILL be dropped by it. No actually he's not, since in domestic situations the noise immunity and jitter level of the connection is sufficient to ensure that no bits will ever be dropped - at least above a 1 in 10 million or so level where we could actually measure it, let alone the one in ten thousand or so where we might actually hear it! I know that! thats why I wrote :- I doubt anyone will actually care about the likelyhood though... Quite so. And yes, I do know that trueGaussian noise implies that a bit *will* be dropped at some point - but how many systems actually contain a true Gaussian distribution? Exactly :) -- 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. |
All times are GMT. The time now is 07:50 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.0.0
Copyright ©2004-2006 AudioBanter.co.uk