SPDIF is evil

[pfarrell]

(starting a new thread)

Themis wrote:
> 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/

[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 stay close to 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 a good option.

[pfarrell]

Themis wrote:
> 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.

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.

--
Pat Farrell
http://www.pfarrell.com/

[Themis]

(starting a new thread)

Themis wrote:
> 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]

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

[pfarrell]

Rodney_Gold wrote:
> 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.

--
Pat Farrell
http://www.pfarrell.com/

[pfarrell]

Rodney_Gold wrote:
> 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.

--
Pat Farrell
http://www.pfarrell.com/

[DCtoDaylight]

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