I2S: Is it a good external interconnect? Give your opinion and findings!

[timequest]

Idiot_Savant and Chris,

 

I couldn't agree more - that's why I love this site/forum. I bought the darn thing so I have a "vested interest."

 

I hope that once mine arrives, it will be everything that I remember the demo units to be (and more!!!).

 

I do not want to be the idiot who puts words in the mouths of others. I went back to the PSA site to review what I remember reading. Here is what was said in regard to the aforementioned review:

It was stated that, "What is missing in the measurements is the throughput jitter rate from PWT, in native mode. The PWT output jitter is under 50ps and the jitter rate of native depends on the jitter rate of the source." It was also said that, "I wish we had the equipment to do so, but we rely on the actual jitter specs of the output asynchronous clock in the PWT which is well below 1ps."

 

So, you can see were my information was derived. I hope that puts it in a different perspective, because I really don't think the person who made the statements is one to blow smoke. I certainly don't want to be responsible for making a misleading statement.

 

 

[idiot_savant]

I genuinely hope ( and think ) you will have an excellent time with your purchases, and would say that choosing stuff to buy based on hearing it is one of the best ways that it can be done ( I don't know circumstances, but would trust that it was done properly ).

My take here is that the ultimate sound is obviously the most important thing, but that if manufacturers make a claim that "this is why it sounds better", and it's measurably not the reason, then why is it?

So, in this case, I don't have one in front of me, and in terms of jitter, I don't really care about how much comes out of the Transport ( if I care at all ), but probably will about it at the DAC ....

 

many people may say measurements don't matter, and I can appreciate that point of view, but only if they aren't quoted to start with as a selling point...

 

your friendly neighbourhood idiot

 

[CG]

Wow! This is really impressive! It'd be truly *amazing* if someone could get 1 ps of jitter inside a real world DAC chip at these frequencies, even with a stupendous clock applied to it.

 

This is partly why specifying jitter in terms of the time domain is kind of lame. The real correct way is to do it in the frequency domain, so that you can tell actually tell what the noise sideband amplitude is and the frequency characteristic. That also allows comparison of actual phase noise over different operating frequencies.

 

For example, in my day job I worry about clocks with femtoseconds of jitter. That sounds really cool and exotic, but in many ways it isn't as difficult as attaining 10's of picoseconds of jitter in a clock for audio use. Why? The operating frequencies are *way* different.

 

http://en.wikipedia.org/wiki/Jitter

 

http://en.wikipedia.org/wiki/Phase_noise

 

 

 

[timequest]

Keep in mind that the reported jitter – via the aforementioned review article, was in native mode (with no up-sampling of any kind). The PWD also has several options for up-sampling and filtering (which dramatically reduce jitter – that’s what up-sampling DACs do). Interestingly, the same reviewer said that native mode “sounded” so good that he couldn’t understand why PSA even bothered with the up-sampling options. That same magazine awarded the PWT/PWT their highest award (Editor’s Choice Award).

 

[icebreaker]

"Then why does the new PS Audio PWT/PWD sound so (extremely) good utilizing their proprietary I2S interface? "

Just a guess but maybe its because the Perfect Wave Transport sits on top of the Perfect Wave DAC and so the I2S only travels less than 6 inches. ?

 

[cfmsp]

 

yes, the Digital Lens is IN the transport.

 

and apparently another will be in the soon-to-be released Bridge piece.

 

That's the problem with using a non Asynchronous protocol I guess, even if it's proprietary, you're putting the fancy clock with low jitter where it doesn't matter - well ahead of the DAC.

 

The more I read about these devices, the less they make sense to me personally, but then I like simple, effective solutions. I don't think you need a special transport, and a special reclocker, and a special DAC. Give me a good async dac and a computer, and I'm good to go.

 

I will say this: the marketing material is the hands-down absolute best I've ever read. To believe even 10% of it, you'd still have to assume that the Perfect Wave is indeed perfect.

 

As Bob Katz has proven, and many others have said, there's no real jitter until digital gets converted to analog, i.e. in the DAC. Bob made a 99 generation copy of digital file to another digital file, with no apparent degradation.

 

PS Audio uses the Digital Lens in the Transport as part of the approach to totally separate (isolate?) the output of the Transport from the CD/DVD read mechanism. They make a big fuss about using an Asynchronous clock and Digital Lens in the transport, along with a buffer, but the end result is just another version of the original digital file (as read by the laser), and so, it's mostly for naught, at least as I understand it.

 

In addition, they are using a master clock from the source component, rather than the DAC, so they are impacted by the inherent problems of non Async DACs, plus whatever additional challenges they've incurred by going to I2S.

 

Did mention the marketing material on the website?

 

It reads really well.

 

 

[cfmsp]

 

First, I'm happy for you that you've found equipment that will make you happy.

 

BUT,

I've been to the PS audio site recently, prior to your suggestion. And I can tell you, that while the kool-aid was good, I didn't see enough there to convince me to put these products on my shortlist.

 

You said earlier that the comparison with several products you mentioned (earlier PS Audio, DAC1, ARC, etc) was unfair. I would tend to agree with you. For this PS audio DAC to be "truly something special", not to mention "in another league", it's gonna have to beat out DACs stronger than the 'B' team that you've compared to. None of those products that you mentioned would even make it on to my long list (for a possible upgrade from my $1500 Metric Halo ULN-2 Firewire DAC), let alone my shortlist.

 

The top DACs (in the price range of the Perfect Wave gear) in my view are the Berkley (a top S/PDIF), the Weiss Minerva (a top Firewire), the brand new Metric Halo ULN-8 (aka Sonic Studio 304 and Amarra Model 4, also Firewire), and the Wavelength (top Async USB) and Ayre DACs (another Top Async YSB), and more I'm sure I'm forgetting. If the PS Audio Dac is to be considered "in another league" and "truly something special" it would need to beat out these DACs (at least in my book) and with enough margin that one could pass a blind test.

 

Granted when all is said and done, the Transport, DAC and Bridge with Lens will be an interesting set of products with impressive functionality (albeit more than I need), but what will the total price be? So far, we've got a $2999 Transport, a $2999 DAC. Wanna bet that the Bridge with Lens will also cost $2999?

 

and I can't help but ask - why should a $6k Transport/DAC combo need a Digital Lens (reclocker)?

 

Oh wait, never mind, I think I know the answer - is it because it's not using asynchronous mode like Firewire or Async USB?

 

respectfully,

clay

 

 

 

 

 

 

 

 

 

 

[timequest]

Clay:

 

Have you heard the Perfect Wave Devices? (I think you have not), and let me say, I sure as heck wouldn't ramble on about something that I have no experience with. My point here was that I have heard the devices. Now, to your point, I have not heard some of the other products that you mentioned and I have no doubt that they are excellent.

 

For what it's worth, I only purchased the DAC, as I am more interested in the server aspects (once the forthcoming Bridge becomes available). By the way, have you ever heard a Rick Cullen, Stage IV Modded DL-III? This is a very good DAC, and the PWD (just the DAC) was in a totally different league.

 

 

[The Computer Audiophile]

Jitter specs aside and personal subjective opinions on the sound aside, these products do have a pretty cool feature set. I'm glad that PS did put a lot of time and money into the product's development and it made some pretty smart decisions along the way. The fact that PS included the CEntrance 24/96 native USB code was a good decision. Sure it's not Async, but it's the best adaptive implementation I've heard based on the other products I've listened to that use this code. PS Audio also did a very good job of insuring the touch screen is very fast. There is nothing worse than a slow moving touch screen where you don't know if you've pressed the right spot or not. This touch screen is very nice.

 

I am very interested in the Bridge concept as well.

 

[Mr.C]

In regards to the PWD measurements and comments on jitter, didn't the Wavelength cosecant measure poorly compared to s/pdif in stereophile? Point being that measurements often don't do justice to the device being measured. What if I2S measures worse in jitter but sounds better than s/pdif?

 

@ clay

To answer a few questions from my product research on the PS audio site.

"Wanna bet that the Bridge with Lens will also cost $2999?"

 

I believe it will be $500 for the bridge and is an module for the PWD. Also, this will eliminate the need for a computer/ transport, so put the final price at around $3500.

 

"and I can't help but ask - why should a $6k Transport/DAC combo need a Digital Lens (reclocker)?"

 

The bridge is for taking network signals/ directly accessing a NAS. It wouldn't be in the Transport-Dac chain.

 

"Oh wait, never mind, I think I know the answer - is it because it's not using asynchronous mode like Firewire or Async USB?"

 

The bridge will be like asynchronous and firewire because the data will remain data until it is converted to signal within the dac.

 

 

 

[Tog]

boring...

 

I wonder what would happen if you just considered what the 6k bundle of joy sounds like - or if the jitter in the Wavelength had no impact on the sound - or if we have really escaped the Emperor's New Clothes World of hi-end hifi.

 

anyway i must get back to my jitter proof s/pdff cable made from twisted strontium 90 - a snip at 62k a metre but it does add a certain upfront fluidity to the sound.

 

 

yours,tog

 

 

 

 

 

[manisandher]

@cfmsp

 

In your earlier post, you said, "That's the problem with using a non Asynchronous protocol I guess, even if it's proprietary, you're putting the fancy clock with low jitter where it doesn't matter - well ahead of the DAC."

 

I think you've got to be careful here. 'Async' is not the only way of ensuring the DAC clock is acting as the master. If your transport/interface has a wordclock input (usually 75 Ohm BNC), then you can feed the wordclock from the DAC back to the transport/interface (assuming the DAC has a wordclock output). And this is totally synchronous.

 

Mani.

 

[laurent]

 

As Gordon Rankin puts it once, please don't give jitter too much importance and go to your dealer and listen.

I regret the tendency here to say that anything that is not asynchronous cannot be a good dac. Unfortunately it is not that simple.

Pro audio asynchronous frirewire Dac have been in the market for years and are still there. You can buy them for a few hundreds dollars from M Audio, Tc electronic, Apogee, Rme...

Do they sound the same just because they are asynchronous? Then why audiophile products cost ten times more?

Going asynchronous is certainly a good thing but it is only one of the aspect of a Dac.

All wavelength products are now asynchronous and yet the price ranges from 1000$ to more than 10 000$.

The best Weiss Dac, the Medea (which is said to be extraordinary but out of my price range) has no firewire or asynchronous usb input. The same with the berkeley alpha dac.

 

As for I-2S cable, I am really surprised to read that it should make a device sound like a 49$ cd player. I think that people from Ps audio have ears and are able to use it. The same with Mr Nugent from Empirical audio. His top products use I2s cables.

So any listening experience of those products is most welcome.

 

 

 

[cfmsp]

 

"'Async' is not the only way of ensuring the DAC clock is acting as the master."

 

Totally agreed. You are correct.

 

As I said very recently (but perhaps in another thread), I'm certain that any protocol can be made to sound excellent, some just require more expense.

 

I prattled on a little too much on the thread (thanks Tog) - no doubt a negative reaction to the 'hype' I read on the PS Audio site, and here.

 

Neither had I gotten all the details straight about the Bridge/Lens (as it's not an available product yet and details are not as readily available). Thanks Mr C, for clarification.

 

clay

 

[Audio_ELF]

Okay ... Now I'm really dense. Everyone is talking about the PWT / PWD combo having a Digital Lens - the only google reference to digital lens is a 90s product which is basically a large FIFI buffer - is this why you mean?

 

Eloise

 

[cfmsp]

 

"The bridge will be like asynchronous and firewire because the data will remain data until it is converted to signal within the dac."

 

Now we're gettin' somewhere.

 

thanks for the explanation.

 

[cfmsp]

Eloise,

 

I had mistakenly thought that the original 'digital lens' was a reclocker device (but that product is from ten years ago or so)

 

In looking at the PS Audio site last night - before having a bad reaction to the kool-aid - I read that in the PW Transport PS go to great pains to separate (via buffers, I think) the data file that was read by the laser from the data file that will be 'clocked' (and then sent on to the DAC).

 

PS refer to this as an Asynchronous clock, even though it's in the Transport. So it shouldn't be confused with an Asynchronous protocol using DAC's clock as master, but the clock is Asynchronous from the clock which was used to read the CD/DVD.

 

With Mr C's help this morning, I came to realize (at least I think I do) that this 'buffering' (as you surmise) and Asynchronous clock in the transport IS the Digital Lens concept.

 

Does that help?

 

clay

 

 

 

[PeterSt]

okok haha

I must honestly say I didn't dare to ask the same question Eloise, although it must have been in the 80's I had one. I recall it didn't bring much, but I guess my ears were not open to jitter at the time.

Oh, maybe they still are not.

 

[Audio_ELF]

I've done a little bit of detective work and come up with this...

 

The original Digital Lens device was from a company calle Genesis who made speakers mostly. Reviewed in Stereophile http://www.stereophile.com/digitalprocessors/824/ it was designed by Paul McGowan - the original P in PS Audio who moved to be a partner with Genesis before becoming involved with / owner of PS Audio again.

 

The Digital Lens, from reading the Stereophile review, was basically a 500k buffer that resynced the data coming from a transport - basically (I think) a FIFO buffer as used also by Meridian and Chord (amongst, I assume, others). This should eliminate jitter though with the original Digital Lens there wa potential for the jitter to be reintroduced as the output was via SPDIF which can introduce jitter by itself. I assume that PS Audio in the PWT / PWD combo are using (their proprietory version) of i2s to try to eliminate this jitter.

 

Hope this helps, certainly helped me (assuming I'm on right wavelength).

Eloise

 

[cfmsp]

"I regret the tendency here to say that anything that is not asynchronous cannot be a good dac."

 

You're right of course, as was Mani.

 

Perhaps what should be said instead is: IN MY OPINION, the most effective way to minimize jitter is to put a very high quality 'clock' in the DAC, and use this as the master, either asynchronously (perhaps easiest to implement) or synchronously (in the manner Mani points out). This is not just my opinion, I stole it from Bob Katz.

 

This is why you can't use any random Firewire device and achieve suitable results, not all will have a high quality clock. The better pro audio devices (with ADCs and DACs) will necessarily have high quality clocks because the livelihood of it's users will depend on it, but much of the gear sold as pro audio today is for home studios, the so-called prosumer market.

 

"Do they sound the same just because they are asynchronous?"

 

No, of course, not. The protocol used is just a starting point. Altho, for reason's I've articulated in other threads - despite that I think wonderful sounding DACs can be built with any protocol - I'd still only consider DACs as described above.

 

Call me crazy, but I want the money I spend to be used to reinforce the best engineered (IMO) approaches and support the companies that best develop them (IMO). We vote with our dollars/pounds/et al, and perhaps with the dollars of those whose purchasing decisions we might subtly influence, so if it appears that my posts are a sort of 'campaign', that is why. I'll pay extra for a product created by a company that I can greatly respect, and whose philosophy I can agree with. Indeed I know the names of the designers of all the audio gear that I now own (except for cables and the Apple products I use peripherally).

 

cheers,

clay

 

 

 

 

 

 

[manisandher]

What I'm really interested in knowing is how the 'new' ways of using the DAC as master (asynchronous USB, isosynchronous firewire, I2S, etc) manage to match the I/O wordclock impedance correctly. If not done properly, there will be severe overshoot, which would negate the benefits of using the DAC as master.

 

The 'old' way uses 75 Ohm BNC connectors/cables. IMHO, this remains the ONLY 'correct' way of doing this...

 

Please feel free to put me straight.

 

Mani.

 

[cfmsp]

 

"how the 'new' ways of using the DAC as master (asynchronous USB, isosynchronous firewire, I2S, etc) manage to match the I/O wordclock impedance correctly"

 

At the risk of boring Tog again, and of being chastised for daring to talk about a device that I've not heard (indeed, nor that many people have heard since it's only been release a matter of days ago ), I'll share my understanding.

 

Better minds than mine will correct me, hopefully.

 

First off, there are two modes of Firewire - native (aka isochronous) and asynchronous. To the best of my knowledge, Isochronous is not used in audio playback (except to stream data from a firewire external drive).

 

Asynchronous mode of firewire (ditto for USB) does not use a separate word clock device requiring impedance matching of external terminations. Firewire is a peer-to-peer protocol, and so the required driver software in the DAC communicates (back to the source) the rate/flow of data desired from the source based on the timing of the DAC's clock. No (separate) wordclock is necessary in this type of implementation.

 

I seem to recall that I2S has an optional Async capability, but if PS Audio are using it, they are not letting on. A recent search of their site/forum on the word 'asynchronous' only resulted in hits on their use of an Asynchronous clock in the Digital Lens, which is NOT within the DAC, but rather within the Transport, and upcoming Bridge. I'm not aware of any attempts on the part of PS to use a separate Wordclock.

 

My DAC has a wordclock input/output but as I use the asynchronous mode Firewire connection, I've not seen the need to use it, not would I have anything to connect it to, short of trying to sync multiple recording devices.

 

Perhaps I misunderstood your question. I'm less knowledge about the various 'clock' elements passed along with the signal in S/PDIF or I2S implementations, for the reason that these implementations don't interest me. If you were referring specifically to the word clock internal to the I2S data stream, I cant help you much.

 

cheers,

clay

 

 

 

[manisandher]

Clay,

 

For the record, isochronous IS used in audio (by Weiss at least).

 

You wrote, "Firewire is a peer-to-peer protocol, and so the required driver software in the DAC communicates (back to the source) the rate/flow of data desired from the source based on the timing of the DAC's clock. No (separate) wordclock is necessary in this type of implementation."

 

Now, this is where I get confused. Yes, peer-to-peer I get. But my understanding is that asynchronous/isochronous USB/firewire DACs don't simply 'communicate' the rate/flow of data, but actually provide the clock to the computer. I.e. the DAC's clock is in someway imbedded in the protocol. And this being the case, I cannot see how this can be achieved accurately without taking into account impedance matching.

 

The only alternative I can see is if a FIFO buffer is used in the DAC, in which case the rate/flow of data from the computer wouldn't be an issue (as long as it was high enough).

 

Where am I going wrong?

 

Mani.

 

[Audio_ELF]

Isochronous is a separate issue from Asyncronous IIRC.

 

Isochronous is a mechanism where the two ends of the transfer (i.e. DAC and Computer) negotiate how much bandwidth is available.

 

Asyncronous data transfer is where the computer sends data when requested by the FireWire / DAC interface (based on it's internal clock) as opposed to Adaptive transfer where the computer sends data based on it's internal clock "ticks".

 

That's how I understand it anyway. I (somewhere) have something from dCS describing it better but that's the just of it. The dCS U-Clock an Scarlatti Upsampler use BOTH asyncronous transfer and isochonous negotiation.

 

Eloise

 

[idiot_savant]

Both firewire and USB have 2 conceptual methods for one device to talk to the other. The first of these, known as asynchronous mode in firewire, and interrupt or bulk mode on USB is to do with low-overhead communications, e.g. one device telling another device what it is, changing the volume, indicating a change of sample rate etc. the key in BOTH of these is that there is no guarantee when the data will arrive at the other end - it is NOT time critical.

The second ( in both protocols ) is called Isochronous - this basically means that the time IS guaranteed, because both sides allocate a certain amount of bandwidth to guarantee a packet sent by one end gets to the other in time for it to be useful.

So, typically, you plug in your audio device into something, both sides talk "asynchronously", agree how much stuff their going to send to each other, what they are called, what they can do, and when you press "Play", the audio is streamed Isochronously.

Now, the problem is that the USB mode we want to use for audio is called Asynchronous Isochronous mode - this is because the audio is now asynchronous to the USB timing, but is terribly confusing for people used to, say, firewire, to whom asynchronous ischronous is a contradiction!

I'm not familiar with the firewire audio ( as it doesn't seem to be as well standardised as USB ), but I would imagine that the DAC has a FIFO which is filled Isochronously, and an asynch message is used for rate control.

In asynch USB, it works by there being a FIFO in the DAC, and TWO isochronous "pipes" - one for feedback ( DAC->PC ), and one for the audio ( PC->DAC )

The upshot of both these methods is that the DAC clock drives the rate of data, so the effect is the same as sending a clock ( over time ) - there is definitely no actual clock, and the phase problems you might imagine are why there are FIFOs on both ends

 

Mani, you are correct to worry about impedance matching, but this will only affect the DAC if it is using a real wordclock for timing...

 

There is definitely no I2S async spec.

 

And none of this has to do with asynchronous rate conversion ( which I've stated I feel is the wrong solution )

 

your friendly neighbourhood idiot