SPDIF is evil

[Pat Farrell]

(starting a new thread)

In any case, it would have been much better if in the digital audio
protocol the clock was explicitly indicated by the A/D (in the data)
and stored with it. This way, transport wouldn't have to add its own
jitter.
Now, whatever is done, we can't go back.

Er, SPDIF is done, but its not the end of the world.

SP/DIF was designed by Sony and Philips defined it as a inexpensive
consumer interface. And while AES was aimed at the studio recording
market (i.e. professionals) it is not designed to be better. Other than
using XLR connectors and not having the "do not copy" bit in the stream,
its exactly the same spec.

All of the problems with timing and clocks could be trivially fixed by
adding one extra wire to the cable, and sending clock. (and a bit of
signaling protocols to allow each end to argue over who is in charge of
the clock).

This would not prevent the cable from adding jitter, but you wouldn't
care, as any delay in the clock will also impact the data signal.

In time, if there is sufficient demand, a new standard could evolve.

As a wise man said: Standards are great, there are so many of them to
chose from

[Themis]

Well, thank you for starting a new thread (I was a bit shy, to be
honest).

So, the idea was : to include the A/D clock in the initially recorded
data.
This could allow all the intermediate "transports" to do just that :
transport the initial data (and clock, thus) without adding anything to
the stored data. Whatever the number of intermediate transports the
data+clock would remain unchanged.

In the end, the overall error would be the one introduced by the D/A
process trying to imitate whatever timing error was initially recorded.

Perhaps it's a naive point of view, but, from the data+clock integrity
point of view this is probably the best option. :)

[Pat Farrell]

Post by Themis
So, the idea was : to include the A/D clock in the initially recorded
data.
transport the initial data (and clock, thus) without adding anything to
the stored data. Whatever the number of intermediate transports the
data+clock would remain unchanged.

Close. actually, the clock becomes irrelevant with data on the "disk"
then it is just data. But when recording, you need to have all of your
ADC on the same clock. You need meta data to say what clock rate is
applicable to the data, but the actual clock timing is no longer important.

Then on playback, you pull the data off the "disk", and create a clock
of the appropriate rate, and send the clock and data together.

Of course, "disk" is just a storage place, it could be a flash drive,
hard disk, or TCP/IP link.

[Themis]

Post by Pat Farrell
(starting a new thread)

In any case, it would have been much better if in the digital audio
protocol the clock was explicitly indicated by the A/D (in the data)
and stored with it. This way, transport wouldn't have to add its own
jitter.
Now, whatever is done, we can't go back.

Er, SPDIF is done, but its not the end of the world.
SP/DIF was designed by Sony and Philips defined it as a inexpensive
consumer interface. And while AES was aimed at the studio recording
market (i.e. professionals) it is not designed to be better. Other than
using XLR connectors and not having the "do not copy" bit in the stream,
its exactly the same spec.
All of the problems with timing and clocks could be trivially fixed by
adding one extra wire to the cable, and sending clock. (and a bit of
signaling protocols to allow each end to argue over who is in charge of
the clock).
This would not prevent the cable from adding jitter, but you wouldn't
care, as any delay in the clock will also impact the data signal.
In time, if there is sufficient demand, a new standard could evolve.
As a wise man said: Standards are great, there are so many of them to
chose from
--
Pat Farrell
http://www.pfarrell.com/

This an excellent idea, too. :)

[DCtoDaylight]

Recognizing that SP/DIF is less than ideal, the next step is obvious,
propose an implement a new standard. The problem with this, is the vast
majority of the marketplace see's nothing wrong with SP/DIF, and isn't
going to pay anything more for it....

In fact, in addition to the separate word clock, there has been another
standard proposed, and implemented by some manufactures: the I2S
interface (I squared S). This derives from another Sony/Philips spec, a
buss intended for IC to IC communication inside a CD player. The name
is an abbreviation of Inter-IC Sound buss.

The original version (championed by Audio Alchemy) used a DIN connector
to handle the extra pins required. Not the best connector, as it isn't
a controlled impedance connection, but at least it did split the data
and clocks. Ultra Analog developed an improved version of this
interface dubbed I2S enhanced, which extended the spec to allow for the
clock to be sourced from either the DAC or Transport. It used a 13W3
connector, which is an odd looking beast used by high end graphics
terminals. Externally, it looks like a DB25 but is interesting in that
it has 3 75ohm coaxial cable connections along with 5 twisted pairs.
Wadia (who ultimately bought out Ultra Analog) and Sonic Frontiers had
products which made use of this interface.

The point of all of this, is that better interfaces have been proposed,
implemented, marketed, and failed.... Sad to say, but I think we're
stuck with SP/DIF.......

[Rodney_Gold]

With 99% of all music lovers thinking that Mp3 is as good as it gets and
with 20+ years of legacy products using the evil spdif, what chance is
there of mnfgrs introducing yet ANOTHER digital standard?
Do you think another digital audio transmission interface would make
such a massive difference to sound quality that its really justified?
--
Rodney_Gold

Sb3/Z-sys RDP1/meridian DSP5500's
TP/X-cans v3/Senns 650's
TP/SCM 50a's
SB3/Meridian DSP5000's
TP/PS audio perfectwave DAC/woo audio Wa2 Headphone amp/Sehneisser
Hd800's

"The nicest thing about smacking your head against the wall is...the
feeling you get when you stop"
------------------------------------------------------------------------
Rodney_Gold's Profile: http://forums.slimdevices.com/member.php?userid=14618
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[Rodney_Gold]

PS audio use I2S via hdmi cable...of course it sounds better , according
to them , with one of their specilaised cables....
--
Rodney_Gold

Sb3/Z-sys RDP1/meridian DSP5500's
TP/X-cans v3/Senns 650's
TP/SCM 50a's
SB3/Meridian DSP5000's
TP/PS audio perfectwave DAC/woo audio Wa2 Headphone amp/Sehneisser
Hd800's

"The nicest thing about smacking your head against the wall is...the
feeling you get when you stop"
------------------------------------------------------------------------
Rodney_Gold's Profile: http://forums.slimdevices.com/member.php?userid=14618
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[Pat Farrell]

Post by Rodney_Gold
PS audio use I2S via hdmi cable...

Is I2S related to I2C? I2C is used all over the place.

I was thinking that to make it have a chance, the new "better audio DIF"
would have to use an existing commodity cable, such as USB 3.0 or HDMI.
But I don't know if you can use these cables without using the
appropriate full protocol.

[DCtoDaylight]

Post by Pat Farrell
Is I2S related to I2C? I2C is used all over the place.

Not really... I2C is a general purpose, two wire buss, clock and data,
with formats for addressing different devices on the buss etc.

I2S is a much simpler three wire interface, with a bit clock, a L/R
word clock, and a data signal.

Cheers, Dave

[netchord]

back in the day, i recall the original Proceed transport and DAC (the
PDT and PDP)had Toslink, COAX, and Balanced connections, as well as a
proprietary Proceed connection that used a special glass cable (the
connector was not toslink). i spent an afternoon listening, and thought
the sound of the proceed connection and XLR were very close, with the
latter being perhaps slightly better (and susceptible to tweaking with
different cables). COAX and Toslink were 3rd and 4th, respectively.

i understand the XLR *output* of the transporter is much better than
either SPDIF output. is the same true of the XLR *input*?

[Phil Leigh]

Post by netchord
i understand the XLR *output* of the transporter is much better than
either SPDIF output. is the same true of the XLR *input*?

Sean who designed the TP stated otherwise quite recently. The AES/EBU
output is not as good (or at least no better) than the coax s/pdif, with
the toslink the worst. How much this matters depends on your DAC.
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[seanadams]

Post by Phil Leigh
Sean who designed the TP stated otherwise quite recently. The AES/EBU
output is not as good (or at least no better) than the coax s/pdif, with
the toslink the worst. How much this matters depends on your DAC.

Just to clarify I was talking about AES/EBU _in general_. There's
nothing wrong with how I did Transporter's AES/EBU output. The interface
is defective by definition, and therefore not possible to execute
reasonably by anyone.

Linky: http://forums.slimdevices.com/showthread.php?t=71262. Also note
JohnSwenson's comments about the high voltage.

[Phil Leigh]

Post by seanadams
Just to clarify I was talking about AES/EBU _in general_. There's
nothing wrong with how I did Transporter's AES/EBU output. The interface
is defective by definition, and therefore not possible to execute
reasonably by anyone.
Linky: http://forums.slimdevices.com/showthread.php?t=71262. Also note
JohnSwenson's comments about the high voltage.

Oh no I didn't mean to imply you had! - I'm sure you did the best you
could.
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[Themis]

Post by seanadams
Just to clarify I was talking about AES/EBU _in general_. There's
nothing wrong with how I did Transporter's AES/EBU output. The interface
is defective by definition, and therefore not possible to execute
reasonably by anyone.
Linky: http://forums.slimdevices.com/showthread.php?t=71262. Also note
JohnSwenson's comments about the high voltage.

I understood it the right way, too. No worries Sean. ;)

[netchord]

Post by Phil Leigh
Sean who designed the TP stated otherwise quite recently. The AES/EBU
output is not as good (or at least no better) than the coax s/pdif, with
the toslink the worst. How much this matters depends on your DAC.

my question was about the TP XLR *input*,, vs its other digital inputs.
in my experience, the toslink definitely does not sound as good s Coak,
but i've only been able to listen to the BNC input via an adapter, and
the XLR input, not at all.

[Phil Leigh]

Post by netchord
my question was about the TP XLR *input*,, vs its other digital inputs.
in my experience, the toslink definitely does not sound as good s Coak,
but i've only been able to listen to the BNC input via an adapter, and
the XLR input, not at all.

Inputs/outputs = same problem. AES/EBU is a flawed design. Sean has
done his best. Stick with coax or BNC (which in theory is the best since
at least the impedance can be properly matched - but not with an
adaptor!).
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[tonyptony]

I've been following the Touch info while still using my SB3 and Duet and
was wondering...

Sean (or John S. or Phil L. if you've measured it), what is the output
return loss from the Touch SPDIF? And, if the numbers are available,
over what bandwidth?

[kphinney]

An article I found:

http://www.nanophon.com/audio/towards.pdf

[seanadams]

Post by tonyptony
Sean (or John S. or Phil L. if you've measured it), what is the output
return loss from the Touch SPDIF? And, if the numbers are available,
over what bandwidth?

I'm not an expert on RF measurements but I doubt if that is a good
metric per se for s/pdif performance when we can observe jitter
directly. For example, we already know that RCA connectors have issues
but that is really a minimal factor compared to things like the
oscillator's noise and the particular design's s/pdif transmitter
circuitry. However, do check out ar-t's TDA measurements which are
really interesting.

The tests I usually did were with a Lecroy 64xi reporting RMS variance
from an ideal time interval, in a few configurations:

1) to measure the internal oscillators and to look for the added jitter
as signal passed through logic gates (prior to s/pdif encoding), I would
use the standard lecroy probe with a modified bayonet tip, having a
minimal ground lead. This is where we get figures like "11ps at the
oscillator" or "17ps at the DAC" for Transporter.

2) to measure the jitter of the s/pdif signal I would usually use an
RG6 cable with an RCA crimped directly on one and and a BNC crimped
directly on the other end. The RCA goes into the Squeezebox and the BNC
goes into a tee with a terminating resistor right onto the scope input.
The Lecroy has the ability to recover a clock from an arbitrary data
signal. This is where we get figures like "50 ps at the DAC".

3) there is another test that is interesting which is to feed an s/pdif
receiver chip and look at the MCLK coming out of it. Sometimes I would
do this with Transporter's outputs looped to it inputs. I did not spend
a whole lot of time on this but it was an interesting way to see the
total performance difference between the various media.

If anyone actually has a high-end scope and would like to try these
sort of tests I could provide more guidance on how to do it. I think
it's a shame that everyone seems content to speculate about jitter while
so few people actually test it.

[Listener]

I think it's a shame that everyone seems content to speculate about

jitter

while so few people actually test it.

Sean, I think you just described the problem with most the high-end
audio industry. Not just jitter measurements but every aspect of audio
performance.

Bill

[Phil Leigh]

Post by tonyptony
I've been following the Touch info while still using my SB3 and Duet and
was wondering...
Sean (or John S. or Phil L. if you've measured it), what is the output
return loss from the Touch SPDIF? And, if the numbers are available,
over what bandwidth?

I don't have the expensive equipment to measure this... and it will be
cable/DAC dependant.

I'm sure Pat from A.R.T. would have a view...

It's generally a good idea to use a long s/pdif cable (but not too
long) to avoid reflections messing with the transition timings. What
difference this makes depends on the DAC.
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[ar-t]

Post by Phil Leigh
I don't have the expensive equipment to measure this... and it will be
cable/DAC dependant.
I'm sure Pat from A.R.T. would have a view...
It's generally a good idea to use a long s/pdif cable (but not too
long) to avoid reflections messing with the transition timings. What
difference this makes depends on the DAC.

It is AR-T, thank you. I think there is a company called A.R.T. but I
don't know them.

Yes, it does make a difference, depending on the DAC.

What is too long? And why?

Pat

[Phil Leigh]

Post by ar-t
It is AR-T, thank you. I think there is a company called A.R.T. but I
don't know them.
Yes, it does make a difference, depending on the DAC.
What is too long? And why?
Pat

Pat - Apologies, I was typing from memory. At least I got the letters
correct!

Too long might be say >10-20m (depending on the quality of the cable) -
I've had problems in the studio with s/pdif cables that long.
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[ar-t]

Ah.........but that is AES/EBU, right? I have coax cables that are
longer than that in use.

Pat

[Phil Leigh]

Post by ar-t
Ah.........but that is AES/EBU, right? I have coax cables that are
longer than that in use.
Pat

Yes they were AES/EBU. I've never tried a s/pdif coax longer than 5m so
can't comment on them. AFAIK the main thing is to make it not too short.
I use 1.5m minimum coax cables.
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[NewBuyer]

...What is too long? And why?...

Hi Pat,

Just checking my memory here please - did you previously mention
somewhere, that about sixteen feet of good coaxial cable with BNC
terminations, was your own recommendation for S/PDIF delivery?

[ar-t]

Well, sort of. 16' is a number that we chose to agree on. It could have
just as easily been...........oh, I dunno..........12'. Or 22'. The
whole point was to make something that was long enough to do the job. A
few extra feet thrown in for good measure. You can go a lot further, and
not degrade the signal significantly.

Pat

[NewBuyer]

Post by ar-t
Well, sort of. 16' is a number that we chose to agree on. It could have
just as easily been...........oh, I dunno..........12'. Or 22'. The
whole point was to make something that was long enough to do the job. A
few extra feet thrown in for good measure. You can go a lot further, and
not degrade the signal significantly.
Pat

Hi Pat,

If using such a long S/PDIF coax cable for a short distance: Is it
appropriate to just coil-up the extra coax cable? I've previously been
advised that coiling the unused cable-length within audio setups can
cause problems & should be avoided - but perhaps this doesn't apply to
S/PDIF coax connections?

[arnyk]

ar-t;491667 Wrote: [color=blue]
If using such a long S/PDIF coax cable for a short distance: Is it
appropriate to just coil-up the extra coax cable?

Yes. Don't be mislead by all the BS about digital cables that is being
passed around by audiophiles that lack the ability to properly test
their claims.


------------------------------------------------------------------------
arnyk's Profile: http://forums.slimdevices.com/member.php?userid=64365
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[Pat Farrell]

Post by Rodney_Gold
With 99% of all music lovers thinking that Mp3 is as good as it gets and
with 20+ years of legacy products using the evil spdif, what chance is
there of mnfgrs introducing yet ANOTHER digital standard?
Do you think another digital audio transmission interface would make
such a massive difference to sound quality that its really justified?
from .sig
meridian DSP5500's

Folks who are willing to pay for Meridian gear would gladly pay for it.
The MP3 is good enough folks will assume we are all from Mars.

But this is the audiophiles list. we are all a bit weird already. And we
can dream.

A large percentage of current SPDIF users don't care much about audio
quality. Most that are used are in home theater rigs, where volume of
booms is much more critical. Additionally, I'd bet that most folks who
own gear with SPDIF connectors never use them, they have been standard
on motherboards for years.

[Pneumonic]

I too think we are stuck with SPDIF which is unfortunate. It appears the
two remedies are to employ an external clock to hopefully counter the
woes that the flawed SPDIF protocol may impart on the sound you hear or
to put everything into one box in order to avoid SPDIF in the first
place.
--
Pneumonic

Main:

Transporter
Squeezebox 3 > Metric Halo ULN2
.................... > Sonic Frontiers Ultra Jitterbug > Roksan DAC/PS
Modwright Sony SCD 777ES
Sonic Frontiers SFL-2 Preamp
Quicksilver Silver 90 Mono Power amps
Martin Logan CLS IIa Speakers

Office:

Squeezebox 3 > Lite Audio DAC60
Muse Model One Preamp
Quicksilver 8417 Mono Power amps
Vandersteen 2Ci Speakers
------------------------------------------------------------------------
Pneumonic's Profile: http://forums.slimdevices.com/member.php?userid=10091
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[miklorsmith]

My big-rig setup includes a hacked SB3 with all analog circuitry removed
that has been converted entirely to a bit-server. Its secondary clock
has been removed and the master clock bypassed to an additional
connector on the outside of the unit. It cannot run without an outboard
clock signal, and was modded with my Lessloss DAC as clock.

The Lessloss unit can operate in 'slave' mode, i.e. normal spdif mode,
or it can act as clock-master with 'data in' and 'clock out'. The DAC
replaces the transport superclock signal, these guys are WAY into the
question of clocking,jitter, and solutions:

http://www.lessloss.com/page.html?id=41

http://www.lessloss.com/page.html?id=33

http://www.lessloss.com/page.html?id=42

It takes two digital cables to run, one for data and the other for
clock, so a little more complex. The SB3 mod was pretty cheap, a couple
hundred bucks of a modder's time - that's the good news. The bad news
is the DAC isn't cheap, about $4,500 today. Hey this IS the audiophile
forum. :)

The results are quite special. I've had quite a group of nice DACs and
CDPs through the house and this is the best I've heard. I have a modded
Rega CD transport that can take advantage of the feature too, though
they now recommend CEC transports which have the clock input feature
standard.

It wouldn't be that hard for manufacturers to include the
master-clocking feature Without any change in format. The connectors
are the same, the data and clock streams are the same - just separated.

In my experience it's completely worthwhile to do this but honestly,
even the audiophile folks aren't talking about it.

[radish]

I have two other, more-typical SB3s but it would be great if a single
unit could be bought off the shelf that would give either option.

You mean a Transporter, right?

[miklorsmith]

Post by radish
You mean a Transporter, right?

I believe the Transporter's clock input is wordclock? Frequencies are
based on the sampling rate, in the kilohertz range? The Lessloss
solution operates in the superclock/megahertz range, which they believe
is better. I'm a technical idiot, but I believe the Transporter's
system is different.

JohnSwenson - that sounds very neat!

[bhaagensen]

Finding a replacement protocol for spdif isn't, and shouldn't, be a
complicated technical matter. The only thing needed is a properly
asynchronous protocol. There are lots of them, but why not choose
something which can be implemented using off-the-shelf components.

TCP/IP could be one choice, but its probably too complicated and
overkill (i.e. does too many things). Asynchronous USB could be another
choice, which I believe is already used in some transports/dacs today.
Such a choice would also narrow the "compatibility" gap with a lot of
present equipement. In terms of needed hardware it would be dead cheap I
believe.

HDMI.... well if becomes a political matter, I'm sure all is set for a
catfight.

[Pat Farrell]

Post by bhaagensen
TCP/IP could be one choice, but its probably too complicated and
overkill (i.e. does too many things). Asynchronous USB could be another
choice, which I believe is already used in some transports/dacs today.
Such a choice would also narrow the "compatibility" gap with a lot of
present equipement. In terms of needed hardware it would be dead cheap I
believe.

Why would you suggest an asynchronous protocol? The whole problem, if
there is any, with jitter is that its not synchronized well enough.

Just include a clock signal with the existing data signal, and joy and
happyness.

Post by bhaagensen
HDMI.... well if becomes a political matter, I'm sure all is set for a
catfight.

Yeah, anytime you get the record industry and the movie industry into
technology, its very ugly.

[bhaagensen]

Post by Pat Farrell
Why would you suggest an asynchronous protocol? The whole problem, if
there is any, with jitter is that its not synchronized well enough.

Because carrying the signal asynchronously as far as possible in the
chain is a simple solution which by definition avoids any (replay-chain)
generated jitter, since there won't be any. It has to get synchronous at
some point, but this should be as close to the dac-chip as possible. At
least in the "same box" so that the DAC, "source point" and the bus
connecting them can be driven off the same crystal. Thats IMO the best
solution, since its a solution by design and hardware wise it should be
a no-brainer today...

[khewa]

Post by bhaagensen
Because carrying the signal asynchronously as far as possible in the
chain is a simple solution which by definition avoids any (replay-chain)
generated jitter, since there won't be any. It has to get synchronous at
some point, but this should be as close to the dac-chip as possible. At
least in the "same box" so that the DAC, "source point" and the bus
connecting them can be driven off the same crystal. Thats IMO the best
solution, since its a solution by design and hardware wise it should be
a no-brainer today...

I'm contemplating getting the Legato USB to SPDIF converter
(http://www.analogresearch-technology.net/LEGATO.html), which is using
the USB asynchronous technology to convert the USB data to SPDIF signal.
In your opinion, this product would not lead to a substantial
improvement in the sound quality, as it is not as close to the source
(the input USB data) as possible ? in effect, the Legato has it's own
clock and the DAC that it is connected to will have another clock. If
that is the case, the Legato product will not merit any consideration.

[JohnSwenson]

I don't have Sean's scope but I have been measuring jitter indirectly
using a spectrum analyzer on the clock (not the audio out, but the clock
itself). This is quite sensitive to changes in jitter, you can see
spectrum changes going through gates as Sean mentioned and its also very
good for looking at a recovered clock coming out of an S/PDIF receiver.
I can easily see the difference that different connectors and cables
make in the recovered clock.

What it doesn't give you is a single number, you have to interpret the
spectrum. Different types of spectrum that have the same "ps number" can
sound very different, which is why I prefer to use this method rather
than the direct time measurement. (well the real reason is that I have a
good spectrum analyzer and I don't have a really good time domain jitter
analyzer and very little chance of getting enough money to buy one!)

With the mentioned legato converter you still have to go through the
S/PDIF receiver in the DAC. You would be MUCH better off putting the
guts of the legato in the DAC and running the DAC off its clock. You can
still use the S/PDIF connection for the data since the recovered clock
will not be used. Of course the DAC has to use an 11.2896 MHz MCLK.

John S.

[ar-t]

Post by JohnSwenson
I don't have Sean's scope but I have been measuring jitter indirectly
using a spectrum analyzer on the clock (not the audio out, but the clock
itself). This is quite sensitive to changes in jitter, you can see
spectrum changes going through gates as Sean mentioned and its also very
good for looking at a recovered clock coming out of an S/PDIF receiver.
I can easily see the difference that different connectors and cables
make in the recovered clock.
What it doesn't give you is a single number, you have to interpret the
spectrum. Different types of spectrum that have the same "ps number" can
sound very different, which is why I prefer to use this method rather
than the direct time measurement. (well the real reason is that I have a
good spectrum analyzer and I don't have a really good time domain jitter
analyzer and very little chance of getting enough money to buy one!)
John S.

Thank you! How many forums have I posted this on, for how many years?
Jitter, as a number, all alone, is pretty useless. First off, you have
to know whether you are talking about bit-clock rate, word-clock rate,
or what frequency. A good number at word-clock rate would be awful at
bit-clock rate.

And then you need to frequency content, as well. Without that, the
numbers mean virtually nothing.

Looking a jitter on a spectrum analyzer is possible, but only if it is
pretty gross. Which it will be in the case of the bit-clock in a SPDIF
RX circuit. (That is why folks either use a ASRC or a secondary PLL.)
Yes, you can see a difference in connectors and such.

A really clean source, such as the clock in a certain product that is
not made by Logitech/Slim Devices, can not be measured in that manner.
No one here, other than you-know-who, has the ability to measure it.

Pat

[Phil Leigh]

Post by khewa
I'm contemplating getting the Legato USB to SPDIF converter
(http://www.analogresearch-technology.net/LEGATO.html), which is using
the USB asynchronous technology to convert the USB data to SPDIF signal.
In your opinion, this product would not lead to a substantial
improvement in the sound quality, as it is not as close to the source
(the input USB data) as possible ? in effect, the Legato has it's own
clock and the DAC that it is connected to will have another clock. If
that is the case, the Legato product will not merit any consideration.

The USB output of what exactly?
--
Phil Leigh

You want to see the signal path BEFORE it gets onto a CD/vinyl...it
ain't what you'd call minimal...
SB Touch Beta (wired) - TACT 2.2X (Linear PSU) + Good Vibrations S/W -
MF Triplethreat(Audiocom full mods) - Linn 5103 - Aktiv 5.1 system (6x
LK140's, ESPEK/TRIKAN/KATAN/SEIZMIK 10.5), Townsend Supertweeters, Blue
Jeans Digital,Kimber Speaker & Chord Interconnect cables
Kitchen Boom, Outdoors: SB Radio
------------------------------------------------------------------------
Phil Leigh's Profile: http://forums.slimdevices.com/member.php?userid=85
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[ar-t]

Why are you people discussing a non-Slim Devices product on their
forum?

If you want to know how it works, you could just ask. But this is not
the time or place to do so.

If you want to talk about SPDIF BW and return loss requirements, then I
am probably the guy to ask. But no one did. I don't get it.

Pat

[kphinney]

Post by ar-t
Why are you people discussing a non-Slim Devices product on their
forum?
If you want to know how it works, you could just ask. But this is not
the time or place to do so.
If you want to talk about SPDIF BW and return loss requirements, then I
am probably the guy to ask. But no one did. I don't get it.
Pat

Where is _your_ forum located?

[kphinney]

Post by ar-t
No, it was originally designed to be used as a test port during
manufacture. The marketing guys are the ones who probably had the idea
it wasn't really intended to be one.)
Pat
Why are you people discussing a non-Slim Devices product on their
forum?
If you want to know how it works, you could just ask. But this is not
the time or place to do so.
If you want to talk about SPDIF BW and return loss requirements, then I
am probably the guy to ask. But no one did. I don't get it.
Pat

Perhaps you should add this information to _your_ forum and correct the
wiki located at:
http://en.wikipedia.org/wiki/S/PDIF
And the Hardware Book here:
http://www.hardwarebook.info/S/PDIF
TC Electronics and Tanoy here:
http://tcsupport.custhelp.com/cgi-bin/tcsupport.cfg/php/enduser/std_adp.php?p_faqid=1305&p_created=1067521162&p_topview=1
And even PS Audio here:
http://www.psaudio.com/ps/wiki/SPDIF/

BTW, if we can't discuss here, where exactly is your forum?

[ar-t]

Post by kphinney
Perhaps you should add this information to _your_ forum and correct the
http://en.wikipedia.org/wiki/S/PDIF
http://www.hardwarebook.info/S/PDIF
http://tcsupport.custhelp.com/cgi-bin/tcsupport.cfg/php/enduser/std_adp.php?p_faqid=1305&p_created=1067521162&p_topview=1
http://www.psaudio.com/ps/wiki/SPDIF/
BTW, if we can't discuss here, where exactly is your forum?

We don't have a forum. Our product is discussed at other
audiophile-related forums. (The only one that I follow is on Audio
Circle. There are others, but I tend to avoid those places.) I don't
think that discussing it here is appropriate, as one could say that it
competes with the Duet et al. The folks who make those products might
not appreciate it.

Pat

[JohnSwenson]

Even though I'm generally in the "evil S/PDIF" camp my latest DAC
actually uses S/PDIF (coax or optical). But I'm using both an in and an
out stream. The DAC generates a stream that is has all zeros for data,
this is fed to a soundcard that can sync its output stream to an
incoming stream. It doesn't matter how good or bad the cables are etc
since the timing on the S/PDIF links is not used for anything. The Local
oscillators in the DAC are used to drive the DAC chips.

By doing this I get to use an asynchronous interface without having to
write any drivers, the soundcard manufacturer takes care of that for me.


The best interface would be for something like the Touch to have clock
inputs (NOT a word clock) that drive in instead of its local crystals,
nothing other than a switch needed. The data can still go out over the
existing digital outs. This automatically syncs it up to the device
generating the external clocks and it can still switch between sample
rates. The receiving DAC will have to look at its incoming stream and
figure out what the sample rate is so it can choose the right clock to
use, but that is not particularly difficult.

As for a new interface I'm actually working on one based on netjack
(network protocol for the jack server) which is a very simple protocol
using UDP, its simple enough that it can be implemented entirely in a
cheap FPGA. It uses standard network infrastructure so you can use
regular ethernet cable, switches etc. It doesn't just have to use
special hardware, it uses standard low level protocols so a computer can
talk this directly out of its existing Ethernet port. The protocol was
designed for studio use so it supports many channels and sample rates.
Its not just a one to one system, you can have many different devices
connected to the same network and route audio data between them.

John S.

[Rodney_Gold]

Yes of course , my SPDIF and AES outputs on all my gear sound like doo
doo and adopting one of these newfangled not a hope in hell chance of
being adopted universally schemes is going to transform my system , hell
even my wife would be able to hear the difference...from the next room..
:)
--
Rodney_Gold

Sb3/Z-sys RDP1/meridian DSP5500's
TP/X-cans v3/Senns 650's
TP/SCM 50a's
SB3/Meridian DSP5000's
TP/PS audio perfectwave DAC/woo audio Wa2 Headphone amp/Sehneisser
Hd800's

"The nicest thing about smacking your head against the wall is...the
feeling you get when you stop"
------------------------------------------------------------------------
Rodney_Gold's Profile: http://forums.slimdevices.com/member.php?userid=14618
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[miklorsmith]

There's the audiophile spirit - Why try, you probably can't hear the
difference anyway!

[ar-t]

Post by Pat Farrell
(starting a new thread)
Er, SPDIF is done, but its not the end of the world.
SP/DIF was designed by Sony and Philips defined it as a inexpensive
consumer interface.

No, it was originally designed to be used as a test port during
manufacture. The marketing guys are the ones who probably had the idea
to make it a consumer interface. (That is why it stinks as an interface:
it wasn't really intended to be one.)

Pat

[arnyk]

Post by Pat Farrell
(starting a new thread)

In any case, it would have been much better if in the digital audio
protocol the clock was explicitly indicated by the A/D (in the data)
and stored with it. This way, transport wouldn't have to add its own
jitter.
Now, whatever is done, we can't go back.

False claim. One reason why digital signalling is so valuable is that
the digital signal can often be purified by means of regeneration. For
example when it is read off the disc, the digital data stream that is
read from optical disks is highly jittery, and often has errors. These
are generally perfectly removed by the normal functioning of a standard
optical disc player.


------------------------------------------------------------------------
arnyk's Profile: http://forums.slimdevices.com/member.php?userid=64365
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[Golden Earring]

Post by arnyk
False claim. One reason why digital signalling is so valuable is that
the digital signal can often be purified by means of regeneration. For
example when it is read off the disc, the digital data stream that is
read from optical disks is highly jittery, and often has errors. These
are generally perfectly removed by the normal functioning of a standard
optical disc player.

Hi Arny!

I'm fascinated to notice that you've suddenly popped up over here. It's
actually quite spooky but disregarding that, are any of the members who
previously posted on this thread still active on the forum?

I recall that somewhere in the Good Book (which I read once in my youth
for completeness) it says "there is nothing new under the sun". It seems
that a lot of people were using external DACs & the word clock in on the
TP back in the day, although no-one seems to have conducted any kind of
rigorous testing of the ABX kind. It was interesting to find Sean Adams
description of how he derived the quoted measurements for the TP. There
didn't appear to be much consensus amongst the earlier posters as to
which kind of lab measurements would be useful in the context of
external DACs and digital connections...

I believe that your position on this remains that it shouldn't make an
audible difference because the TP's internal jitter is low enough to be
inaudible & similarly that its in-built DAC is good enough to be
indistinguishable from an external DAC in terms of discernible audible
differences in a domestic listening environment with real ears, despite
the possibility that minute measurable differences might be detected in
lab testing. That's if I've understood your "reliable subjectivist"
concept correctly. Please put me right if I've got any of this wrong,
I'm not précising your early statements in my own words to irritate you
but simply to ensure that I've fully got your drift.

On the other thread (which has been getting a bit silly, I must shoulder
my share of the blame for that!) you commented that you should perhaps
write up something on the (or your, I wasn't quite sure) theory of
audible perception in homo sapiens. With my deadly serious face on for
once, I should be most interested to read that.

Hope that you're having a pleasant weekend!

Dave :)


------------------------------------------------------------------------
Golden Earring's Profile: http://forums.slimdevices.com/member.php?userid=66646
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[arnyk]

Post by Golden Earring
Hi Arny!
I'm fascinated to notice that you've suddenly popped up over here. It's
actually quite spooky but disregarding that, are any of the members who
previously posted on this thread still active on the forum?
I recall that somewhere in the Good Book (which I read once in my youth
for completeness) it says "there is nothing new under the sun".

Umm yes, Ecclesiastes.

It seems that a lot of people were using external DACs & the word clock
in on the TP back in the day, although no-one seems to have conducted
any kind of rigorous testing of the ABX kind. It was interesting to find
Sean Adams description of how he derived the quoted measurements for the
TP. There didn't appear to be much consensus amongst the earlier posters
as to which kind of lab measurements would be useful in the context of
external DACs and digital connections...


If you follow the relevant scientific argument that a DAC can only have 4
kinds of technical problems, all of which are readily measurable and for
whom we know quite a bit about the audible thresholds...


I believe that your position on this remains that it shouldn't make an
audible difference because the TP's internal jitter is low enough to be
inaudible & similarly that its in-built DAC is good enough to be
indistinguishable from an external DAC in terms of discernible audible
differences in a domestic listening environment with real ears, despite
the possibility that minute measurable differences might be detected in
lab testing. That's if I've understood your "reliable subjectivist"
concept correctly. Please put me right if I've got any of this wrong,
I'm not précising your early statements in my own words to irritate you
but simply to ensure that I've fully got your drift.


Confirmed.

The TP's internal DAC was tested pretty comprehensively by Archimago in
his blog. If I ever get around to writing that article about understanding
technical measurements in terms of sound quality, the executive summary
can be expected to say that the TP is vast overkill. Of course people say
they sound different, but as you say good listening tests confirming that
are harder to find than rooster teeth.

There are 400 or more different makes and models of audio DACs, each
selling to Audiophiles on the grounds of "Better sound". Technically,
there aren't that many significantly different designs. The vast majority
are based on less than 20 different DAC chips with just a few using
proprietary parts. Almost all of those chips are very good and can't be
logically expected to audibly change the sound of music conveyed by the
analog signals they output. People hoot and holler about differences in
power supplies and buffers, but they are even less likely to affect sound
quality.


------------------------------------------------------------------------
arnyk's Profile: http://forums.slimdevices.com/member.php?userid=64365
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[Golden Earring]

Post by arnyk
Umm yes, Ecclesiastes.
If you follow the relevant scientific argument that a DAC can only have
4 kinds of technical problems, all of which are readily measurable and
for whom we know quite a bit about the audible thresholds...
Confirmed.
The TP's internal DAC was tested pretty comprehensively by Archimago in
his blog. If I ever get around to writing that article about
understanding technical measurements in terms of sound quality, the
executive summary can be expected to say that the TP is vast overkill.
Of course people say they sound different, but as you say good listening
tests confirming that are harder to find than rooster teeth.
There are 400 or more different makes and models of audio DACs, each
selling to Audiophiles on the grounds of "Better sound". Technically,
there aren't that many significantly different designs. The vast
majority are based on less than 20 different DAC chips with just a few
using proprietary parts. Almost all of those chips are very good and
can't be logically expected to audibly change the sound of music
conveyed by the analog signals they output. People hoot and holler
about differences in power supplies and buffers, but they are even less
likely to affect sound quality.

Hi Arny,

Thanks for your prompt & helpful response.

At least I for one appear to have bothered to actually ingest your
posts!

Relaxing into the music now (Emmylou Harris + Mark Knopfler today, All
The Roadrunning + live tour album) then heading into highlights of
Spanish GP. Alonso managed to put his hopelessly underpowered
McLaren-Honda in 7th on the grid. He's looking like a good prospect for
the Indy 500...

All the best,
Dave :)


------------------------------------------------------------------------
Golden Earring's Profile: http://forums.slimdevices.com/member.php?userid=66646
View this thread: http://forums.slimdevices.com/showthread.php?t=71464

[RonM]

Post by Golden Earring
Relaxing into the music now (Emmylou Harris + Mark Knopfler today, All
The Roadrunning

That's exactly what I was doing yesterday, appreciating the technology
uncritically with one of my favorite albums.



LMS on a dedicated server (FitPC3)
Transporter (Ethernet) - main listening, Onkyo receiver, Paradigm
speakers
Touch (WiFi) - home theater 5.1, Sony receiver, Energy speakers
Boom 1 (WiFi) - work-space
Boom 2 (WiFi) - various (deck, garage, etc.)
Radio (WiFi) - home office
Control - Squeeze Control (Android mobile), 2 Controllers (seldom used),
Squeeze Remote (on Surface Pro 4)
Touch x 1 - spare
UE Radio x 1 - spare
Boom x 1 - spare
Controller x 1 - Spare
Duet Receiver (backup)
------------------------------------------------------------------------
RonM's Profile: http://forums.slimdevices.com/member.php?userid=17029
View this thread: http://forums.slimdevices.com/showthread.php?t=71464