Sign in with
Sign up | Sign in
Your question

Digital Coax Cable: Can You Hear The Difference?

Last response: in Home Audio
Share
Anonymous
March 16, 2005 10:17:09 PM

Archived from groups: rec.audio.tech (More info?)

Two questions; I have a cdp connected to a receiver via digital coax.
Is there much audio difference in one dc cable in comparison to
another or will I most likely not be able to hear a difference- if I
go for any kind of upgrade it will most likely be for a cable less
than $40; I'm using a radio shack dc cable now. The other question:
can I use a standard audio cable instead of the digital coax without
any sound degradation or is the coax necessary for sound quality. I
apologize if these are stupid and elementary questions. Thanks.
Anonymous
March 16, 2005 10:17:10 PM

Archived from groups: rec.audio.tech (More info?)

Digital data transmission is, of course, binary in nature, including
that it either works or it doesn't. As long as the receiver can reliably
distinguish ones and zeros then it will read the same data regardless of
whether it is just barely or rock-solidly making that distinction. Only
when that becomes no longer making the distinction might you hear
differences between cables.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
Anonymous
March 16, 2005 11:04:55 PM

Archived from groups: rec.audio.tech (More info?)

In article <bc1h31hktahbec03mhohfi5ct6f776g234@4ax.com>,
soinie <soinie@hotttmail.com> wrote:

>Two questions; I have a cdp connected to a receiver via digital coax.
>Is there much audio difference in one dc cable in comparison to
>another or will I most likely not be able to hear a difference- if I
>go for any kind of upgrade it will most likely be for a cable less
>than $40; I'm using a radio shack dc cable now.

Unless your receiver or CD player are badly broken or very poorly
designed, or the cables are defective, you should hear no difference
at all when switching from one "digital" coax cable to another.

There need be nothing exceptional about a "digital" coax cable. It's
simply a flexible coax having a characteristic impedance of 75 ohms,
and acceptable-quality RCA plugs on the end.

The requirements for a "digital" coax cable are the same as those for
a cable intended to carry "baseband" or "composite" video signals...
75 ohms, RCA plugs.


> The other question:
>can I use a standard audio cable instead of the digital coax without
>any sound degradation or is the coax necessary for sound quality.

I would not use an "audio" coax cable (these usually have red or white
color coding on their RCA plugs). Audio cables don't require any
specific characteristic impedance, and for this reason there's no way
to predict what the characteristic impedance of any given cable might
be. I've been able to do digital-audio transfers over modest
distances (12 - 15 feet) using a datacomm-type coax cable which
probably have a characteristic impedance of 35-40 ohms, but with an
oscilloscope at one end I could see that there were some signal
reflections on the cable. They weren't bad enough to cause data
misreads (and for this reason they had no effect at all on the audio
signal) but if the cable were longer there might have been a problem.

On the other hand, any halfway-decent "composite video" cable (yellow
color coding on the RCA plugs) should work very well indeed for
digital audio.

My guess is that your Radio Shack cable probably quite as good as you
need it to be, and that there's no reason to pour money down a rathole
buying a "better" (more expensive) one.

--
Dave Platt <dplatt@radagast.org> AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Related resources
Anonymous
March 17, 2005 1:17:49 AM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 14:20:28 -0600, TCS
<The-Central-Scrutinizer@p.o.b.o.x.com> wrote:

>And unless the cable is a good fraction of a mile long, impedance matching
>doesn't matter.

A 6 MHz signal has a 50 m/164 ft wavelenght.
Anonymous
March 17, 2005 1:17:50 AM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 22:17:49 +0100, François Yves Le Gal <flegal@aingeal.com> wrote:
>On Wed, 16 Mar 2005 14:20:28 -0600, TCS
><The-Central-Scrutinizer@p.o.b.o.x.com> wrote:

>>And unless the cable is a good fraction of a mile long, impedance matching
>>doesn't matter.

>A 6 MHz signal has a 50 m/164 ft wavelenght.
Anonymous
March 17, 2005 1:17:50 AM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 22:17:49 +0100, François Yves Le Gal <flegal@aingeal.com> wrote:
>On Wed, 16 Mar 2005 14:20:28 -0600, TCS
><The-Central-Scrutinizer@p.o.b.o.x.com> wrote:

>>And unless the cable is a good fraction of a mile long, impedance matching
>>doesn't matter.

>A 6 MHz signal has a 50 m/164 ft wavelenght.
Anonymous
March 17, 2005 1:17:50 AM

Archived from groups: rec.audio.tech (More info?)

In article <sh8h315t7hal6mj35jldgeq62iqsaflaan@4ax.com>,
François Yves Le Gal <flegal@aingeal.com> wrote:

><The-Central-Scrutinizer@p.o.b.o.x.com> wrote:
>
>>And unless the cable is a good fraction of a mile long, impedance matching
>>doesn't matter.
>
>A 6 MHz signal has a 50 m/164 ft wavelenght.

.... in air or vacuum. In a cable with a typical velocity factor (.6 -
..9) it'll be shorter.

Analog-audio cables won't tend to show any symptoms of impedance
mismatch unless they're a good fraction of a mile long, it's true.
That's related to the fact that the signals they're carrying usually
have a bandwidth limited to about 20 kHz.

Cables carrying _digital_ audio, or composite video (similar
signal bandwidths) can and do show the symptoms of impedance mismatch at much
shorter lengths. As I pointed out in the part of my posting that
The-Central-Scrutinizer snipped out, I was able to detect obvious
signs of an impedance mismatch in a digital-audio cable less than 20
feet long. The mismatch wasn't severe enough to cause data errors,
but it was quite obvious on the 'scope.

In my experience, a decent-quality composite-video cable need not cost
any more than an audio cable of similar quality. Heck, I got a 6'
composite-video cable thrown in when I bought a $30 Radeon PC video
card yesterday... couldn't have cost the manufacturer more than a
dollar or so in quantity. I see three-cable-on-one-assembly cables
(one video cable, two audio cables, molded together) on the Net for
all of $5 for a 6-footer and $7 for a 12-footer.

At these prices, I see no reason to "cheap out" and use audio cables
of unknown impedance for digital-audio purposes.


--
Dave Platt <dplatt@radagast.org> AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Anonymous
March 17, 2005 1:17:50 AM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 22:17:49 +0100, François Yves Le Gal <flegal@aingeal.com> wrote:
>On Wed, 16 Mar 2005 14:20:28 -0600, TCS
><The-Central-Scrutinizer@p.o.b.o.x.com> wrote:

>>And unless the cable is a good fraction of a mile long, impedance matching
>>doesn't matter.

>A 6 MHz signal has a 50 m/164 ft wavelenght.


I'll keep that in mind next time I run a cable down the street.
Anonymous
March 17, 2005 1:25:49 AM

Archived from groups: rec.audio.tech (More info?)

>>A 6 MHz signal has a 50 m/164 ft wavelenght.

>I'll keep that in mind next time I run a cable down the street.

As a general rule of thumb, transmission-line effects (including
signal reflections at impedance mismatches) start to be an issue once
a cable reaches 1/10 wavelength at the highest frequency of interest.
On a cable this long, a reflection from the "receiving" end which is
then re-reflected from the "sending" end will be almost 90 degrees out
of phase with the primary signal. If the cable reaches 12.5%
wavelength, then the reflection is precisely 90 degrees out of phase,
and multiple reflections could end up reinforcing one another.

At 6 MHz, this means that a cable with a velocity factor of 1.0 would
only need to be 16 feet. Practical coaxial cables generally have
velocity factors of .65 - .9. In the case of a cable with a solid
polyethylene dielectric (VF of around .65) the cable would only need
to be about 10 feet long.

My guess is that for a short (3') composite-video or digital-audio
cable, one need not worry. For cables of 12' or more, it makes sense
to match impedances. 6' is somewhere in the middle, but as it's so
cheap to "do it right" I'd just use a 75 ohm cable.

--
Dave Platt <dplatt@radagast.org> AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
Anonymous
March 17, 2005 2:40:35 AM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 21:41:57 -0000, dplatt@radagast.org (Dave Platt) wrote:

>At these prices, I see no reason to "cheap out" and use audio cables
>of unknown impedance for digital-audio purposes.

Agreed.
Anonymous
March 17, 2005 2:41:36 AM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 15:48:17 -0600, TCS
<The-Central-Scrutinizer@p.o.b.o.x.com> wrote:

>I'll keep that in mind next time I run a cable down the street.

Yeah, whatever you say.
Anonymous
March 17, 2005 10:47:14 AM

Archived from groups: rec.audio.tech (More info?)

"François Yves Le Gal" <flegal@aingeal.com> wrote in message
news:sh8h315t7hal6mj35jldgeq62iqsaflaan@4ax.com
> On Wed, 16 Mar 2005 14:20:28 -0600, TCS
> <The-Central-Scrutinizer@p.o.b.o.x.com> wrote:
>
>> And unless the cable is a good fraction of a mile long, impedance
>> matching doesn't matter.
>
> A 6 MHz signal has a 50 m/164 ft wavelenght.

Seems about right. Wavelength-related effects start showing up around 1/8
wavelength at the earliest. Furthermore, a 24/96 SP/DIF signal has
appreciable content up to about 12 MHz.

Therefore, being as careful as is reasonable, coax cables over about 10 feet
long need to have the right nominal impedance. Shorter than that, and it
probably won't matter at all. Use that old 1 meter RCA cable with good
continuity and good connectors in good health!

It's a good thing that proper impedance coax cables are commodity items, and
easy to obtain for very reasonable prices.
Anonymous
March 17, 2005 10:48:00 AM

Archived from groups: rec.audio.tech (More info?)

"Dave Platt" <dplatt@radagast.org> wrote in message
news:113ha15a4imb04@corp.supernews.com

> Cables carrying _digital_ audio, or composite video (similar
> signal bandwidths) can and do show the symptoms of impedance mismatch
> at much shorter lengths. As I pointed out in the part of my posting
> that The-Central-Scrutinizer snipped out, I was able to detect obvious
> signs of an impedance mismatch in a digital-audio cable less than 20
> feet long. The mismatch wasn't severe enough to cause data errors,
> but it was quite obvious on the 'scope.
>
> In my experience, a decent-quality composite-video cable need not cost
> any more than an audio cable of similar quality. Heck, I got a 6'
> composite-video cable thrown in when I bought a $30 Radeon PC video
> card yesterday... couldn't have cost the manufacturer more than a
> dollar or so in quantity. I see three-cable-on-one-assembly cables
> (one video cable, two audio cables, molded together) on the Net for
> all of $5 for a 6-footer and $7 for a 12-footer.
>
> At these prices, I see no reason to "cheap out" and use audio cables
> of unknown impedance for digital-audio purposes.

Agreed.
Anonymous
March 17, 2005 3:52:05 PM

Archived from groups: rec.audio.tech (More info?)

On Thu, 17 Mar 2005 07:47:14 -0500, "Arny Krueger" <arnyk@hotpop.com>
wrote:

>Seems about right. Wavelength-related effects start showing up around 1/8
>wavelength at the earliest.

Wavelength effects *peak* at a quarter wavelength. At 1/8 wavelength
they are 0.707 of maximum - a fair bit more than starting showing.
Make that a twentieth of a wavelength and you have it.,

Still going to be insignificant though, whatever.

d

Pearce Consulting
http://www.pearce.uk.com
Anonymous
March 17, 2005 3:52:06 PM

Archived from groups: rec.audio.tech (More info?)

"Don Pearce" <donald@pearce.uk.com> wrote in message
news:423d7cfc.87118000@news.plus.net
> On Thu, 17 Mar 2005 07:47:14 -0500, "Arny Krueger" <arnyk@hotpop.com>
> wrote:
>
>> Seems about right. Wavelength-related effects start showing up
>> around 1/8 wavelength at the earliest.
>
> Wavelength effects *peak* at a quarter wavelength. At 1/8 wavelength
> they are 0.707 of maximum - a fair bit more than starting showing.
> Make that a twentieth of a wavelength and you have it.,
>
> Still going to be insignificant though, whatever.

Agreed.
Anonymous
March 17, 2005 3:52:43 PM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net>
wrote:

>As long as the receiver can reliably
>distinguish ones and zeros then it will read the same data regardless of
>whether it is just barely or rock-solidly making that distinction.

And what would be the jitter threshold?
Anonymous
March 17, 2005 3:52:44 PM

Archived from groups: rec.audio.tech (More info?)

"François Yves Le Gal" wrote:

>On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net>
>wrote:
>
>>As long as the receiver can reliably
>>distinguish ones and zeros then it will read the same data regardless of
>>whether it is just barely or rock-solidly making that distinction.
>
>And what would be the jitter threshold?

Uh, 42?

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
Anonymous
March 17, 2005 11:58:09 PM

Archived from groups: rec.audio.tech (More info?)

On Thu, 17 Mar 2005 11:51:27 -0800, "Michael R. Kesti" <mkesti@gv.net>
wrote:

>Uh, 42?

Only in base 13, or for the Kantor. No, not Ken.

http://www.loyd.net/number.html
Anonymous
March 18, 2005 3:16:14 PM

Archived from groups: rec.audio.tech (More info?)

On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net>
wrote:

>Digital data transmission is, of course, binary in nature, including
>that it either works or it doesn't. As long as the receiver can reliably
>distinguish ones and zeros then it will read the same data regardless of
>whether it is just barely or rock-solidly making that distinction. Only
>when that becomes no longer making the distinction might you hear
>differences between cables.


You don't admit any timing issues for real-time media streaming?
Anonymous
March 18, 2005 3:16:15 PM

Archived from groups: rec.audio.tech (More info?)

"Laurence Payne" <l@laurenceDELETEpayne.freeserve.co.uk> wrote in
message news:6jhl31d5nefvke3i7hv9gm3e32q4tf94qh@4ax.com
> On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net>
> wrote:
>
>> Digital data transmission is, of course, binary in nature, including
>> that it either works or it doesn't. As long as the receiver can
>> reliably distinguish ones and zeros then it will read the same data
>> regardless of whether it is just barely or rock-solidly making that
>> distinction. Only when that becomes no longer making the
>> distinction might you hear differences between cables.
>
>
> You don't admit any timing issues for real-time media streaming?

Not any that can't be readily resolved.
Anonymous
March 18, 2005 3:16:15 PM

Archived from groups: rec.audio.tech (More info?)

Laurence Payne wrote:

>On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>
>>Digital data transmission is, of course, binary in nature, including
>>that it either works or it doesn't. As long as the receiver can reliably
>>distinguish ones and zeros then it will read the same data regardless of
>>whether it is just barely or rock-solidly making that distinction. Only
>>when that becomes no longer making the distinction might you hear
>>differences between cables.
>
>You don't admit any timing issues for real-time media streaming?

OK! OK! I confess! ;-)

Streaming audio timing issues can result in unsatisfactory performance, but:

1) they are not typically due to the differences in coaxial cables, and,

B) they also result in it-works-or-doesn't-work situations.

I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
alleviate problems that result from data that fail to arrive in time.
I'm willing to learn, though!

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
Anonymous
March 18, 2005 4:14:28 PM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 07:42:04 -0500, "Arny Krueger" <arnyk@hotpop.com>
wrote:

>>> Digital data transmission is, of course, binary in nature, including
>>> that it either works or it doesn't. As long as the receiver can
>>> reliably distinguish ones and zeros then it will read the same data
>>> regardless of whether it is just barely or rock-solidly making that
>>> distinction. Only when that becomes no longer making the
>>> distinction might you hear differences between cables.
>>
>>
>> You don't admit any timing issues for real-time media streaming?
>
>Not any that can't be readily resolved.

So let's discuss what these issues are, and how to resolve them.
Anonymous
March 18, 2005 4:35:47 PM

Archived from groups: rec.audio.tech (More info?)

Arny Krueger wrote:
> "François Yves Le Gal" <flegal@aingeal.com> wrote in message
> news:f9ml31lcf4kvdarf760sga8g9t5o8phu6c@4ax.com
> > On Fri, 18 Mar 2005 07:42:04 -0500, "Arny Krueger"
<arnyk@hotpop.com>
> > wrote:
> >
> >> Not any that can't be readily resolved.
> >
> > Come on: such problems *do* exist.
> >Solving them is another matter.
>
> It is routinely done quite well. For example, the signal coming off a
CD
> optical pickup is quite impure, jitter being just one of the serious
> imperfections.

"Jitter being just one of the serious imperfections" is something
of a dramatic understatement.

What most people don't realize is that the data coming off the
CD is not just suffering from jitter, it's coming of the CD
totally scrambled and seriously out of order, by the very nature
of the beast. This is by direct consequence of the encoding and
decoding done on the CD. The data is written with individual
bits scattered across a fairly wide area of the CD track, all
out of order, and comes back off the CD that way. This is way
beyond "jitter." The CD read electronics basically just patiently
wait for the data to come in, reassemble it, decode it and,
then present the decoded, reassembled audio data out after sugnificant
buffering at a rate that is actually fairly independent of the
instantaneous rate at which it came of the CD.

Looking at it from the actual design and implementation, you CAN'T
have "jitter" per se in the raw data coming of the CD: there is
no timing information. The timing information comes from the fact
that the sample is known a priori. The mechanical speed of the
disk itself is being countiuously adjusted, up and down, so, as
to satisfy the buffer requirements of the read system. The incoming
data rate i all over the place by design. The read buffering and
decode systems jib is to take the scrambled (the real word is
"interleaved") data, buffer it, so the output of the read process
can then parcel out the bits as determined by the sample rate, NOT
by the disk speed.
Anonymous
March 18, 2005 5:36:17 PM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 07:42:04 -0500, "Arny Krueger" <arnyk@hotpop.com> wrote:

>Not any that can't be readily resolved.

Come on: such problems *do* exist. Solving them is another matter.
Anonymous
March 18, 2005 6:36:13 PM

Archived from groups: rec.audio.tech (More info?)

"François Yves Le Gal" <flegal@aingeal.com> wrote in message
news:f9ml31lcf4kvdarf760sga8g9t5o8phu6c@4ax.com
> On Fri, 18 Mar 2005 07:42:04 -0500, "Arny Krueger" <arnyk@hotpop.com>
> wrote:
>
>> Not any that can't be readily resolved.
>
> Come on: such problems *do* exist.

I would never deny that this is true.

>Solving them is another matter.

It is routinely done quite well. For example, the signal coming off a CD
optical pickup is quite impure, jitter being just one of the serious
imperfections.
Anonymous
March 18, 2005 8:26:19 PM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 12:16:14 +0000, Laurence Payne
<l@laurenceDELETEpayne.freeserve.co.uk> wrote:

>On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net>
>wrote:
>
>>Digital data transmission is, of course, binary in nature, including
>>that it either works or it doesn't. As long as the receiver can reliably
>>distinguish ones and zeros then it will read the same data regardless of
>>whether it is just barely or rock-solidly making that distinction. Only
>>when that becomes no longer making the distinction might you hear
>>differences between cables.
>
>
>You don't admit any timing issues for real-time media streaming?

Not if you have a properly functioning DAC such as the Benchmark
DAC-1. The whole point of digital technology is that it's *robust*.
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 18, 2005 8:27:37 PM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 14:36:17 +0100, François Yves Le Gal
<flegal@aingeal.com> wrote:

>On Fri, 18 Mar 2005 07:42:04 -0500, "Arny Krueger" <arnyk@hotpop.com> wrote:
>
>>Not any that can't be readily resolved.
>
>Come on: such problems *do* exist. Solving them is another matter.

Arny wrote correctly that there no problems which can't be readily
resolved. Hence, they don't exist. Get a decent DAC.
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 19, 2005 12:12:01 AM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 11:52:54 -0800, "Michael R. Kesti" <mkesti@gv.net>
wrote:

>Laurence Payne wrote:
>
>>On Wed, 16 Mar 2005 17:52:02 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>>
>>>Digital data transmission is, of course, binary in nature, including
>>>that it either works or it doesn't. As long as the receiver can reliably
>>>distinguish ones and zeros then it will read the same data regardless of
>>>whether it is just barely or rock-solidly making that distinction. Only
>>>when that becomes no longer making the distinction might you hear
>>>differences between cables.
>>
>>You don't admit any timing issues for real-time media streaming?
>
>OK! OK! I confess! ;-)
>
>Streaming audio timing issues can result in unsatisfactory performance, but:
>
> 1) they are not typically due to the differences in coaxial cables, and,
>
> B) they also result in it-works-or-doesn't-work situations.
>
>I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
>alleviate problems that result from data that fail to arrive in time.
>I'm willing to learn, though!

That would be because you don't understand that the Benchmark totally
reclocks the incoming data. It's not like the data aren't going to
arrive until sometime next week..................

--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 19, 2005 12:12:02 AM

Archived from groups: rec.audio.tech (More info?)

Stewart Pinkerton wrote:

>On Fri, 18 Mar 2005 11:52:54 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>
>>I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
>>alleviate problems that result from data that fail to arrive in time.
>>I'm willing to learn, though!
>
>That would be because you don't understand that the Benchmark totally
>reclocks the incoming data. It's not like the data aren't going to
>arrive until sometime next week..................

I'm thinking that maybe it has been a while since you have used a dailup
network connection.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
Anonymous
March 19, 2005 12:12:03 AM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 15:08:03 -0800, Michael R. Kesti <mkesti@gv.net> wrote:
>Stewart Pinkerton wrote:

>>On Fri, 18 Mar 2005 11:52:54 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>>
>>>I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
>>>alleviate problems that result from data that fail to arrive in time.
>>>I'm willing to learn, though!
>>
>>That would be because you don't understand that the Benchmark totally
>>reclocks the incoming data. It's not like the data aren't going to
>>arrive until sometime next week..................

>I'm thinking that maybe it has been a while since you have used a dailup
>network connection.

I'll keep that in mind next time I use modems to wire up my audio system.
Anonymous
March 19, 2005 10:11:11 AM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 15:08:03 -0800, "Michael R. Kesti" <mkesti@gv.net>
wrote:

>Stewart Pinkerton wrote:
>
>>On Fri, 18 Mar 2005 11:52:54 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>>
>>>I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
>>>alleviate problems that result from data that fail to arrive in time.
>>>I'm willing to learn, though!
>>
>>That would be because you don't understand that the Benchmark totally
>>reclocks the incoming data. It's not like the data aren't going to
>>arrive until sometime next week..................
>
>I'm thinking that maybe it has been a while since you have used a dailup
>network connection.

LOL! :-)
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 19, 2005 11:09:21 AM

Archived from groups: rec.audio.tech (More info?)

TCS wrote:

>On Fri, 18 Mar 2005 15:08:03 -0800, Michael R. Kesti <mkesti@gv.net> wrote:
>>Stewart Pinkerton wrote:
>
>>>On Fri, 18 Mar 2005 11:52:54 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>>>
>>>>I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
>>>>alleviate problems that result from data that fail to arrive in time.
>>>>I'm willing to learn, though!
>>>
>>>That would be because you don't understand that the Benchmark totally
>>>reclocks the incoming data. It's not like the data aren't going to
>>>arrive until sometime next week..................
>
>>I'm thinking that maybe it has been a while since you have used a dailup
>>network connection.
>
>I'll keep that in mind next time I use modems to wire up my audio system.

Perhaps it was your desire to be a smart-ass that caused you to miss when
Laurence Payne turned the discussion from cables to streaming audio.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mkesti@gv.net | - The Who, Bargain
Anonymous
March 19, 2005 2:29:05 PM

Archived from groups: rec.audio.tech (More info?)

On Fri, 18 Mar 2005 17:27:37 +0000 (UTC), Stewart Pinkerton
<patent3@dircon.co.uk> wrote:

>Arny wrote correctly that there no problems which can't be readily
>resolved. Hence, they don't exist. Get a decent DAC.

Strange usage of "hence"! :-)
Anonymous
March 19, 2005 4:42:54 PM

Archived from groups: rec.audio.tech (More info?)

On Sat, 19 Mar 2005 08:09:21 -0800, Michael R. Kesti <mkesti@gv.net> wrote:
>TCS wrote:

>>On Fri, 18 Mar 2005 15:08:03 -0800, Michael R. Kesti <mkesti@gv.net> wrote:
>>>Stewart Pinkerton wrote:
>>
>>>>On Fri, 18 Mar 2005 11:52:54 -0800, "Michael R. Kesti" <mkesti@gv.net> wrote:
>>>>
>>>>>I fail to see how a better DAC, as suggested by Stewart Pinkerton, will
>>>>>alleviate problems that result from data that fail to arrive in time.
>>>>>I'm willing to learn, though!
>>>>
>>>>That would be because you don't understand that the Benchmark totally
>>>>reclocks the incoming data. It's not like the data aren't going to
>>>>arrive until sometime next week..................
>>
>>>I'm thinking that maybe it has been a while since you have used a dailup
>>>network connection.
>>
>>I'll keep that in mind next time I use modems to wire up my audio system.

>Perhaps it was your desire to be a smart-ass that caused you to miss when
>Laurence Payne turned the discussion from cables to streaming audio.

Of course, and I'll keep that in mind next time I use dial up to stream
audio.
Anonymous
March 19, 2005 11:59:33 PM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:lo3m31hfmkbs33mqtqn3s2ka7omh4pp94e@4ax.com...
> >You don't admit any timing issues for real-time media streaming?
>
> Not if you have a properly functioning DAC such as the Benchmark
> DAC-1. The whole point of digital technology is that it's *robust*.

Actually it's the clock source that will affect jitter, but the keywords
here were "real time media streaming". So presumably were talking about loss
of data or insufficient data buffering, another matter entirely.

MrT.
Anonymous
March 20, 2005 11:58:03 AM

Archived from groups: rec.audio.tech (More info?)

On Sat, 19 Mar 2005 20:59:33 +1100, "Mr.T" <MrT@home> wrote:

>"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
>news:lo3m31hfmkbs33mqtqn3s2ka7omh4pp94e@4ax.com...
>> >You don't admit any timing issues for real-time media streaming?
>>
>> Not if you have a properly functioning DAC such as the Benchmark
>> DAC-1. The whole point of digital technology is that it's *robust*.
>
>Actually it's the clock source that will affect jitter, but the keywords
>here were "real time media streaming".

The Benchmark totally recolcks the datastream.

>So presumably were talking about loss
>of data or insufficient data buffering, another matter entirely.

Indeed, but the OP *is* referring to jitter.
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 20, 2005 11:07:44 PM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:aneq31p1tgj2mjsbld254uj68q13atfv10@4ax.com...
> >> >You don't admit any timing issues for real-time media streaming?

> >So presumably were talking about loss
> >of data or insufficient data buffering, another matter entirely.
>
> Indeed, but the OP *is* referring to jitter.

Jitter doesn't exist for real time media streaming until it is buffered and
clocked out by *any* DAC clock.

MrT.
Anonymous
March 20, 2005 11:07:45 PM

Archived from groups: rec.audio.tech (More info?)

On Sun, 20 Mar 2005 20:07:44 +1100, "Mr.T" <MrT@home> wrote:

>"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
>news:aneq31p1tgj2mjsbld254uj68q13atfv10@4ax.com...
>> >> >You don't admit any timing issues for real-time media streaming?
>
>> >So presumably were talking about loss
>> >of data or insufficient data buffering, another matter entirely.
>>
>> Indeed, but the OP *is* referring to jitter.
>
>Jitter doesn't exist for real time media streaming until it is buffered and
>clocked out by *any* DAC clock.

Of course it exists. The point is that, unless bits are dropped, it
doesn't *matter* until the point of D/A conversion. Sadly, the
majority of so-called 'high end' standalone DACs do *not* use
buffering and/or reclocking. Thae Benchmark DAC-1 is an excellent
example of how to do it right at reasonable cost.
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 22, 2005 10:59:46 PM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:D 5hr31d31ch85da3ku8e3b844bo7ql8spj@4ax.com...
> >> Indeed, but the OP *is* referring to jitter.
> >
> >Jitter doesn't exist for real time media streaming until it is buffered
and
> >clocked out by *any* DAC clock.
>
> Of course it exists.

Bullshit. Stored data has no jitter. It may have errors, but's that's not
the same thing.

>The point is that, unless bits are dropped, it
> doesn't *matter* until the point of D/A conversion. Sadly, the
> majority of so-called 'high end' standalone DACs do *not* use
> buffering and/or reclocking. Thae Benchmark DAC-1 is an excellent
> example of how to do it right at reasonable cost.

All streamed data must be buffered and reclocked, how can it be otherwise,
since the transfer rate varies, and is not tied to the sample rate.
Whether the DAC-1 is an excellent example or reasonable cost is simply a
matter of opinion, but not something I am disputing.

MrT.
Anonymous
March 22, 2005 10:59:47 PM

Archived from groups: rec.audio.tech (More info?)

On Tue, 22 Mar 2005 19:59:46 +1100, "Mr.T" <MrT@home> wrote:

>"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
>news:D 5hr31d31ch85da3ku8e3b844bo7ql8spj@4ax.com...
>> >> Indeed, but the OP *is* referring to jitter.
>> >
>> >Jitter doesn't exist for real time media streaming until it is buffered and
>> >clocked out by *any* DAC clock.
>>
>> Of course it exists.
>
>Bullshit. Stored data has no jitter. It may have errors, but's that's not
>the same thing.

Bullshit yourself, since you referred to *real time media streaming*,
not stored data.

>>The point is that, unless bits are dropped, it
>> doesn't *matter* until the point of D/A conversion. Sadly, the
>> majority of so-called 'high end' standalone DACs do *not* use
>> buffering and/or reclocking. Thae Benchmark DAC-1 is an excellent
>> example of how to do it right at reasonable cost.
>
>All streamed data must be buffered and reclocked, how can it be otherwise,
>since the transfer rate varies, and is not tied to the sample rate.

Depends on the protocol, the transfer rate of the ubiquitous S/PDIF
data stream for instance does not vary more than is caused by jitter,
and this is relied upon by the majority of standalone audio DACs.

--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 23, 2005 9:58:39 PM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:t5m04155vppagbgqalufjt490tepled264@4ax.com...
> >> >> Indeed, but the OP *is* referring to jitter.
> >> >
> >> >Jitter doesn't exist for real time media streaming until it is
buffered and
> >> >clocked out by *any* DAC clock.
> >>
> >> Of course it exists.
> >
> >Bullshit. Stored data has no jitter. It may have errors, but's that's not
> >the same thing.
>
> Bullshit yourself, since you referred to *real time media streaming*,
> not stored data.

Just shows you have NO idea how it actually works!


> >>The point is that, unless bits are dropped, it
> >> doesn't *matter* until the point of D/A conversion. Sadly, the
> >> majority of so-called 'high end' standalone DACs do *not* use
> >> buffering and/or reclocking. Thae Benchmark DAC-1 is an excellent
> >> example of how to do it right at reasonable cost.
> >
> >All streamed data must be buffered and reclocked, how can it be
otherwise,
> >since the transfer rate varies, and is not tied to the sample rate.
>
> Depends on the protocol, the transfer rate of the ubiquitous S/PDIF
> data stream for instance does not vary more than is caused by jitter,
> and this is relied upon by the majority of standalone audio DACs.

You still have NO idea what streaming media actually is do you.

MrT.
Anonymous
March 23, 2005 9:58:40 PM

Archived from groups: rec.audio.tech (More info?)

On Wed, 23 Mar 2005 18:58:39 +1100, "Mr.T" <MrT@home> wrote:

>"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
>news:t5m04155vppagbgqalufjt490tepled264@4ax.com...

>> >All streamed data must be buffered and reclocked, how can it be
>otherwise,
>> >since the transfer rate varies, and is not tied to the sample rate.
>>
>> Depends on the protocol, the transfer rate of the ubiquitous S/PDIF
>> data stream for instance does not vary more than is caused by jitter,
>> and this is relied upon by the majority of standalone audio DACs.
>
>You still have NO idea what streaming media actually is do you.

Sure I do, which is why I'm trying to drag the thread back to where it
belongs - jitter in audio datastreams. As noted, it doesn't *matter*
in small amounts until you get to the point of conversion, but
streaming data certainly does have jitter - get enough of it and
you'll start dropping bits....................
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 24, 2005 10:11:17 PM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:jv63419n5b30d2ablofvcpigq09ls176l5@4ax.com...
> > As noted, it doesn't *matter*
> in small amounts until you get to the point of conversion, but
> streaming data certainly does have jitter - get enough of it and
> you'll start dropping bits....................

OK, I guess your just using a different definition of jitter than the rest
of us then.

MrT.
Anonymous
March 24, 2005 10:11:18 PM

Archived from groups: rec.audio.tech (More info?)

"Mr.T" <MrT@home> wrote in message
news:4242769e$0$29448$afc38c87@news.optusnet.com.au
> "Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
> news:jv63419n5b30d2ablofvcpigq09ls176l5@4ax.com...
>>> As noted, it doesn't *matter*
>> in small amounts until you get to the point of conversion, but
>> streaming data certainly does have jitter - get enough of it and
>> you'll start dropping bits....................
>
> OK, I guess your just using a different definition of jitter than
the
> rest of us then.

AFAIK, Pinkie is using an absolutely orthodox definition of jitter.

The concept of a fixed time base related to the sample rate of the
audio stream is completely blown to smithereens by current
implementations of streaming audio, because they are perceptually
coded. Even streams that are losslessly compressed are relevant to
jitter, only in terms of data loss. They have nothing to do with the
details of the digital audio stream that is converted to audio in a
DAC chip, for example. Massive amounts of timing variations due to the
audio stream received from the audio server at the individual listener
site have to be dealt with.
Anonymous
March 25, 2005 7:25:41 PM

Archived from groups: rec.audio.tech (More info?)

"Arny Krueger" <arnyk@hotpop.com> wrote in message
news:MdWdnbMKNZBSU9_fRVn-qA@comcast.com...
> AFAIK, Pinkie is using an absolutely orthodox definition of jitter.
>
> The concept of a fixed time base related to the sample rate of the
> audio stream is completely blown to smithereens by current
> implementations of streaming audio, because they are perceptually
> coded. Even streams that are losslessly compressed are relevant to
> jitter, only in terms of data loss. They have nothing to do with the
> details of the digital audio stream that is converted to audio in a
> DAC chip, for example. Massive amounts of timing variations due to the
> audio stream received from the audio server at the individual listener
> site have to be dealt with.

I'm sorry Arny, I don't see how these statements coincide. Pinky says there
is jitter in the streamed data before it is clocked out.
I say it's just stored data at the receiving end until it is clocked out.
The concept of jitter in stored data escapes me.

There is no direct correlation between the computer to computer data
transmission rate and the audio bit rate, so variations in the data rate are
not the same as jitter in the audio bit stream.

What is the semantics interpretation that pinky is using to claim he is
right and I am wrong? I still don't see it.

MrT.
Anonymous
March 25, 2005 7:25:42 PM

Archived from groups: rec.audio.tech (More info?)

On Fri, 25 Mar 2005 16:25:41 +1100, "Mr.T" <MrT@home> wrote:

>
>"Arny Krueger" <arnyk@hotpop.com> wrote in message
>news:MdWdnbMKNZBSU9_fRVn-qA@comcast.com...
>> AFAIK, Pinkie is using an absolutely orthodox definition of jitter.
>>
>> The concept of a fixed time base related to the sample rate of the
>> audio stream is completely blown to smithereens by current
>> implementations of streaming audio, because they are perceptually
>> coded. Even streams that are losslessly compressed are relevant to
>> jitter, only in terms of data loss. They have nothing to do with the
>> details of the digital audio stream that is converted to audio in a
>> DAC chip, for example. Massive amounts of timing variations due to the
>> audio stream received from the audio server at the individual listener
>> site have to be dealt with.
>
>I'm sorry Arny, I don't see how these statements coincide. Pinky says there
>is jitter in the streamed data before it is clocked out.
>I say it's just stored data at the receiving end until it is clocked out.
>The concept of jitter in stored data escapes me.

If there's enough jitter in the datasteam, some of the bits will also
escape you..............

>There is no direct correlation between the computer to computer data
>transmission rate and the audio bit rate, so variations in the data rate are
>not the same as jitter in the audio bit stream.

Sure they are - but they don't have the same effect.

>What is the semantics interpretation that pinky is using to claim he is
>right and I am wrong? I still don't see it.

No semantics necessary, jitter is timing instability in the
transmitted data stream.
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 25, 2005 7:25:42 PM

Archived from groups: rec.audio.tech (More info?)

"Mr.T" <MrT@home> wrote in message
news:4243a14c$0$22221$afc38c87@news.optusnet.com.au
> "Arny Krueger" <arnyk@hotpop.com> wrote in message
> news:MdWdnbMKNZBSU9_fRVn-qA@comcast.com...

>> AFAIK, Pinkie is using an absolutely orthodox definition of
jitter.

>> The concept of a fixed time base related to the sample rate of the
>> audio stream is completely blown to smithereens by current
>> implementations of streaming audio, because they are perceptually
>> coded. Even streams that are losslessly compressed are relevant to
>> jitter, only in terms of data loss. They have nothing to do with
the
>> details of the digital audio stream that is converted to audio in a
>> DAC chip, for example. Massive amounts of timing variations due to
>> the audio stream received from the audio server at the individual
>> listener site have to be dealt with.
>
> I'm sorry Arny, I don't see how these statements coincide. Pinky
says
> there is jitter in the streamed data before it is clocked out.

I agree with him.

> I say it's just stored data at the receiving end until it is clocked
> out. The concept of jitter in stored data escapes me.

I agree with that as well.

> There is no direct correlation between the computer to computer data
> transmission rate and the audio bit rate, so variations in the data
> rate are not the same as jitter in the audio bit stream.

Agreed.

> What is the semantics interpretation that pinky is using to claim he
> is right and I am wrong? I still don't see it.

There may be none.
Anonymous
March 26, 2005 1:09:15 AM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:D rf7419su5n5uuklh1897dkdv9pv8ktj73@4ax.com...
> If there's enough jitter in the datasteam, some of the bits will also
> escape you..............

Of course, but it's got nothing to do with the audio sample rate. YOU keep
saying a particular DAC reclocks the data, so does *ANY* DAC with streaming
audio, was my point. I have made clear what I meant a number of times.

> >There is no direct correlation between the computer to computer data
> >transmission rate and the audio bit rate, so variations in the data rate
are
> >not the same as jitter in the audio bit stream.
>
> Sure they are - but they don't have the same effect.

Actually I would say they are different, but have the same effect.

> No semantics necessary, jitter is timing instability in the
> transmitted data stream.

Yes, I never said otherwise. YOU just keep interchanging audio data bits and
computer data at random to suit your argument about some DAC being better
than another because it reclocks the DATA, which ANY DAC will have to do
with streaming media.

If you still don't get it, I don't care. I'm sure you can come up with some
other distraction to claim you are right. If you redefine the argument often
enough, I'm sure you will be.

MrT.
Anonymous
March 26, 2005 1:09:16 AM

Archived from groups: rec.audio.tech (More info?)

On Fri, 25 Mar 2005 22:09:15 +1100, "Mr.T" <MrT@home> wrote:

>
>"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
>news:D rf7419su5n5uuklh1897dkdv9pv8ktj73@4ax.com...
>> If there's enough jitter in the datasteam, some of the bits will also
>> escape you..............
>
>Of course, but it's got nothing to do with the audio sample rate. YOU keep
>saying a particular DAC reclocks the data, so does *ANY* DAC with streaming
>audio, was my point. I have made clear what I meant a number of times.

The point about the Benchmark is that it reclocks S/PDIF, which is
very rare.

>> >There is no direct correlation between the computer to computer data
>> >transmission rate and the audio bit rate, so variations in the data rate
>are
>> >not the same as jitter in the audio bit stream.
>>
>> Sure they are - but they don't have the same effect.
>
>Actually I would say they are different, but have the same effect.

Nope - in the transmitted datastream, it doesn't matter so long as it
doesn't drop bits. At the point of D/A conversion, it's *critical* to
sound quality.
--

Stewart Pinkerton | Music is Art - Audio is Engineering
Anonymous
March 26, 2005 3:39:07 PM

Archived from groups: rec.audio.tech (More info?)

"Stewart Pinkerton" <patent3@dircon.co.uk> wrote in message
news:16r841lfs15mgnulfc6ncmmatd2jd5oaf8@4ax.com...
> The point about the Benchmark is that it reclocks S/PDIF, which is
> very rare.

My sound card can do it, but irrelevant if you are using it's own DAC
anyway.

>>Actually I would say they are different, but have the same effect.
> Nope - in the transmitted datastream, it doesn't matter so long as it
> doesn't drop bits.

I'm glad we now agree on that. Check sums and the ability to retransmit
incorrect data make them different IMO. This can't be done at the DAC.

>At the point of D/A conversion, it's *critical* to sound quality.

Exactly my point. So you do agree there is a difference in the data now?
Hooray!

MrT.
!