Jump to content
IGNORED

New Dichotomy - Async vs. Non-async DACs


cfmsp

Recommended Posts

Hi there,

 

I had a discussion with another friend of mine who tends to believe Firewire DACs are the best implementation of DACs. I argued him the ideal DAC is the one that has music stored in its main memory, such as SRAM or SD card memory. This doesn't involve inter-system connection so that transmission-related noise is minimized.

 

I told him to look at data sheet of all D/A chips. Each of them just need a high-precision oscillator, jitter-free serial data, an analog output stage circuit and a noise-free PSU. This is the ideal basic DAC.

 

The invention of digital audio was restricted to memory and processor technology in 80's. The 600MB of wave file data was stored on a polycarbonate plastic disc delivered to the listener. There was no any other choice to retrieve and transmit the wave files rather than using a CD transport. This is where the clock begins. The counterpart D/A chip just uses that "transmitted" clock to play music.

 

The basic ideal DAC is the opposite to the conventional CD player. There is plenty of memory as if the whole file wave was stored. You just select the right sampling rate in order to play music. That's it.

 

The rest of the equipment are "fancy" things to meet every one's needs ! This is where async and sync sneak in.

 

The best sounding player stores the whole music collection on an SD card and has a fixed-frequency (zero-jitter) DAC, i.e. a single clock design.

 

If you can derive your DAC to the ideal basic DAC, then your DAC would have a chance to sound the best as what the D/A chip is engineered for.

 

Nontheless, one would say "Why worry ! My DAC already sounds very good to my ears !".

 

Link to comment

"the ideal DAC is the one that has music stored in its main memory, such as SRAM or SD card memory. This doesn't involve inter-system connection so that transmission-related noise is minimized."

 

Sounds like the Nova Physics Memory Player.

 

Other Hiends DACs that need to be added to Paul's list of the "definition of reference:"

 

Playback Designs

MSB

Wadia

Esoteric

ALP Hi-Fi NWO-DAC1

 

I agree there's more to digital playback than just Async vs. Non-async, take a look at the digital output pictures of the ART Legato USB-SPDIF converter:

 

http://www.audiocircle.com/index.php?topic=67762.20

 

Link to comment

 

"Asynchronous USB

I’ve been getting a few calls and emails about USB connectivity between your computer and your DAC and what I think about asynchronous vs. synchronous. Apparently there’s a few DACS out now that are sporting asynchronous USB that allows streaming of 96kHz audio. I am being asked what I think about this.

 

Here’s the deal: our PWD is one of the few that handles 96kHz audio streaming from a computer, but it is not asynchronous. I know a few newer DACS use asynchronous USB to stream 96kHz.

 

As to the question which is better, the answer’s pretty clear: asynchronous. Asynchronous clocks are what’s used in the PerfectWave transport and as long as you implement it properly, it’s clearly a better way to go when streaming digital audio data. No question about it.

 

So, our customers are asking me why we don’t switch over to asynchronous USB for the PerfectWave DAC and the answer’s really simple: there’s really no reason. USB is hopelessly limited to lower sample rate audio and it must always be tethered to a computer.

 

I don’t know about you, but for my money these two hurdles are simply too much to get in the way. It’s kind of like asking whether coax or balanced is better on S/PDIF - the answer is balanced, but who cares? I want to listen to real high-resolution audio, which for me starts at 176.4kHz and I don’t want a computer anywhere near my listening area. Certainly 96kHz is better than 44kHz but it’s a short-term answer.

 

The best solution is just around the corner and it’s called the PS Network Bridge. The Bridge will connect your computer or storage via your network and stream any sample or bit rate completely asynchronous; delivered to the PWD via I2S without any jitter or problems. You don’t even need a computer actually, all you’ll need is an online storage device (like a NAS) which can be placed anywhere in the house you like. It’s that simple and elegant and it can even be wireless if you want.

 

So, while USB is currently about the only way to enjoy high-resolution audio through your computer, in my opinion, it’s a short-term solution. The best way to listen to high-resolution audio will be through the Bridge when it ships out in a couple of months. Until then, if you get a chance to play around with one of these DACS, it’ll give you a great glimpse into the future of high-resolution audio. Go for it."

 

 

clay

 

Link to comment

Gang,

 

I designed one of the first intelligent Ethernet 10/100 boards back when I was at DCA. We needed a board for the PPP dial up server we developed back in the 1990. I wrote bridging code for Ethernet, Token Ring and a freaken bunch of crap that I cannot even remember. Ethernet and iP are very respected but there is a lot more overhead than direct interfaces like USB and Firewire. Also USB/Firewire are designed for short run minimum connectivity. Ethernet and IP are not they are setup for the big picture. USB/Firewire are both running over 4x the amount of data that Ethernet can provide. While I am sure you could get easily 24/192 out of Ethernet it would be a lot of development to integrate it into any application on the host controlling the dac.

 

~~~~~~~~

 

Jitter....

 

There are basically three clocks in digital audio which can be subject to jitter:

Master Clock (MCLK) usually 256x, 512x or 768x the sampling rate. Master clock for the system.

Bit Clock (SCLK, BCLK) usually 64x the sampling rate. Used to shift out the data to and from devices.

Word Clock (WCLK) at FS or sampling rate is used to determine if the data is for the RIGHT or LEFT channel.

 

All systems typically take the MCLK and divide it down to the WCLK. In this division jitter is added at a minimum of 3dB per times 2 division. In other words all clocks are divided by 2 and then 2 then 2 till we reach WCLK. Therefore the minimum jitter from MCLK to WCLK is 24dB increase (256x or 8*3dB). This is theoretical as the power supply of the unit doing the dividing will increase the jitter. Typically DSP's, 32 Bit ARM and other big processors add more as they have a lot of clock multipliers which add ground noise. FPGA/CPLD's can get very close to 24dB, TAS1020B is more like between 30dB and 35dB depending on power supply and stuff.

 

We use as the standard WCLK as the reference to measure jitter because this will have the highest jitter and will also represent how well the MCLK was developed since WCLK was derived from MCLK.

 

Using the 2ps number as the one thrown around on this thread would not represent the jitter in the WCLK. As a 0.12ps of jitter Master Clock would be first hard to test for and also hard to develop and keep consistent. It probably represents the Master Clock which is a fair number, not great, but fair. Most modern Oscillators are between 0.5ps and 1ps of jitter. Now to get that you have to power the damn thing with an ultra low noise regulator something in the area of 10nVrms to 25nVrms of noise from 1Hz and above. Also it should be noted that it is very easy to get say 0.5ps of jitter at 100Hz, but a lot harder to get that at 10Hz.

 

So there are a lot of numbers, this does not represent much and the customer should better off listen to the product instead of buying it for the numbers.

 

~~~~~~~~~

 

Jitter part 2...

 

Ok so in any computer audio setup... we have parallel data and we convert that to serial audio data and this is were the jitter starts. If you have jitter before that... it does not matter. For this discussion anything that effects the parallel data will only cause data errors and for this discussion let's assume those errors are 0.

 

Adaptive method be it Firewire or USB will have to change the MCLK on the fly to assure that the parallel data is full enough so that the digital audio stream does not overrun or underrun. What this means is kind of like cruise control. The clock is the cruise control and varies as the car goes up or down the hill to maintain a constant speed. The big problem here is this movement of the clock is adding significant jitter to the system. Remember what I said above....

 

A fixed digital audio based oscillator will always out perform an oscillator that is moving to match some incoming stream.

 

So for adaptive systems a jitter reduction method is a requirement. But with all the jitter reduction methods these become like filters. None of these can filter out all the jitter. The more jitter you have the more that is going to go through. Nothing is going to be the silver bullet here or as Charlie Hansen says so often the "Free Lunch".

 

~~~~~~~~

 

Asynchronous

 

Again this can be Async USB using the spec and native drivers or any BULK mode concept with a device driver making it look like BULK (typically used for hard drives) is really and Audio Output device.

 

Here we use a fixed clock as the Master Clock and create the Bit and Word clock from this.

 

See there is not reason to change this clock. Well unless the computer says use a different rate and we need to change the clock. We need two clocks for most Digital Audio (I2S, L/R justified, DSP whatever). One for 44.1, 88.2 and 176.4 and another for 48, 96 and 192. So as long as we have a really clean low jitter Master Clock there is no reason to use any jitter elimination systems as there is no moving clock and therefore the intrinsic jitter to create the I2S link is as low as it is going to get.

 

~~~~~~~~

 

Asynchronous pt 2

 

Now the TAS1020B, DSP's ARM whatever have the capabilities to create their own Master Clocks at literally any frequency. These are done using what is called a Frequency Synthesizer which is what most Adaptive devices use to change their Master Clocks. But we could in an Async environment set this and forget it and create a stable Master Clock. The problem here is the jitter is very high because the process used to create these clocks has very high phase noise. Phase Noise is what causes jitter and with a Frequency Synthesizer there will always be high jitter and this adds to the Adaptive problem.

 

~~~~~~~~

 

PS Audio Newsletter

 

Gang I got mine yesterday and then this morning had another 30 in my mail box with some rather funny things attached by reviewers, customers, friends and other designers.

 

First Paul I don't know who you are talking to but Channel Islands did not develop this it is part of the USB Specification and anyone could implement it if they wanted or tried to. So far in high end audio besides myself, I think dCS is the only other company who has cracked the puzzle.

 

I Paul admitted that Asynchronous is better as I hope I have explained above.

 

But really who ever is asking Paul for this do realize that the boards are setup for the Adaptive Protocol that CEntrance has setup for PS Audio. Therefore they are using the Frequency Synthesizers that are built into the TAS1020B.

 

So even if PSA bought the Asynchronous code from some other company and put it into the socket they use for the CEntrance code now.... it would not automatically make this a good solution. Better... sure a little but not great.

 

See you have to feedback into the TAS1020B the really low Master Clocks to make this truly good solution.

 

Again no matter what you read there is no way to remove all the jitter from the Adaptive concept.

 

Lastly Paul, I have implemented now a total of 5 HS USB solutions to 32/192. I have pared that down to 2 solutions and have that working with Class 2 USB Audio on the MAC already without drivers. Hoping by the end of the year to be sampling one or both of them.

 

Thanks

Gordon

 

Link to comment

I'll poke my head up just long enough to add one comment.

 

Trying to get your head around the concept of jitter in the time domain can be really misleading.

 

In a digital conversion scheme, what really counts is the frequency domain performance of the clocking system.

 

Think of a DAC as a frequency converter (or multiplier to be specific). Any spurious tone or noise on the actual conversion clock (NOT the same as what is applied to the clock of the DAC - various things inside the DAC degrade the effective clock) will mix with the desired signal generated by the applied data stream to produce an output spectrum that is not faithful to the original. These aren't the traditional harmonics or even the IMD products found in an amplifier, even though the fundamental mathematical process is the same. The pollution is totally unlike anything heard in nature or a concert hall.

 

So, an actual phase plot of the clock is far more useful than a simple jitter number. Even if it takes more interpretation.

 

Link to comment

Thanks. And very good news on your headway for getting higher data rates out of the ASYNC USB connection. Thanks for all of your hard work on the USB interface. For the way I set up and use my system, the simplicity of going from a computer to a DAC via USB or Firewire is the way to go. Once I get my hands on a USB/Firewire DAC capable up to 24/192 I look forward to leaving my system alone, forgetting about all this technical stuff (ha ha) and listening to as much music as I have time for.

 

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment

Gordon-

 

I know that Pat is using your Streamlength Technology in his Legato. I've tried a prototype and I'm waiting for a production unit.

 

I posted the link to his audiocircle post to show Pat's attention to detail on the unit's digital output.

 

Aloha,

 

Dan

 

Link to comment

Below are my thoughts on the PS Audio newsletter.

 

All quotes are from Paul McGowan of PS Audio.

 

"Here’s the deal: our PWD is one of the few that handles 96kHz audio streaming from a computer, but it is not asynchronous. I know a few newer DACS use asynchronous USB to stream 96kHz."

 

There are substantially more than a 'few' DACs that handle 96kHz streaming from a computer. There are more than a 'few' that handle 176/192.

 

Though not USB, the Metric Halo ULN-2 has offered 96kHz asynchronous streaming since 2003!

 

"As to the question which is better, the answer’s pretty clear: asynchronous. Asynchronous clocks are what’s used in the PerfectWave transport and as long as you implement it properly, it’s clearly a better way to go when streaming digital audio data. No question about it."

 

Kudos for agreeing that Asynchronous clocking of data in a DAC is superior, about which more below.

 

"So, our customers are asking me why we don’t switch over to asynchronous USB for the PerfectWave DAC and the answer’s really simple: there’s really no reason. USB is hopelessly limited to lower sample rate audio and it must always be tethered to a computer."

 

This statement about USB should use the word 'currently', rather than 'hopelessly'.

 

As for USB needing to be tethered to a computer, well, yes, but what's the problem here, and if there is one, how is his solution different?

 

Paul's Network Bridge will ALSO require connection to the PWD in some manner, presumably I2S. An HDMI cable is no less a 'tether' than a USB cord, indeed, when carrying I2S signal, it will require a more restricted (read shorter) 'tether'. NOTE: many believe the I2S signal is meant for signal paths measured in centimeters, not meters.

 

While it's true that the Network Bridge would not likely be called a computer, I maintain that it may be a distinction without a (significant) difference, when compared to, for instance, a dedicated Mac Mini music server (used in headless fashion).

 

We'll need to see the Bridge when it finally surfaces for a more detailed comparison, but from a purely physical standpoint, the Mac Mini will likely not suffer in a comparison to the Bridge, with respect to size, power reqts, noise (Mac Mini is dead quiet even before installation of the 'de rigeur' SSD), and any other likely reasons that Paul has for objecting to having a 'computer' in the listening environment.

 

"I don’t know about you, but for my money these two hurdles are simply too much to get in the way. It’s kind of like asking whether coax or balanced is better on S/PDIF - the answer is balanced, but who cares? I want to listen to real high-resolution audio, which for me starts at 176.4kHz and I don’t want a computer anywhere near my listening area. Certainly 96kHz is better than 44kHz but it’s a short-term answer."

 

Despite the dearth of music available at these highest of resolutions, many playback options are available now, via Firewire and AES DACs.

 

Paul is also conflating issues here - the DAC is the limiting factor for higher resolution file handling, not the computer that he supposes to relegate to the 'home office'.

 

"The best solution is just around the corner and it’s called the PS Network Bridge. The Bridge will connect your computer or storage via your network and stream any sample or bit rate completely asynchronous; delivered to the PWD via I2S without any jitter or problems."

 

Hmm, so in order to remove the 'computer' from the listening room, we only have to insert Paul's 'box'.

 

I guess that should be a plus for some, perhaps many. Great marketing for sure, IF one actually doesn't actually wind up using their computer to interface with it.

 

As for 'without any jitter', well, it doesn't appear that the I2S connection is done asynchronously, which Paul has declared as the best method of communicating data via USB. Does he believe I2S protocol is somehow immune to the physics of digital data communication protocols?

 

Can you say 'misdirection'? :)

 

"You don’t even need a computer actually, all you’ll need is an online storage device (like a NAS) which can be placed anywhere in the house you like. It’s that simple and elegant and it can even be wireless if you want."

 

Without a computer, what will the Bridge use for a player? Will the user be able to use their preferred music playing software, e.g., Amarra, iTunes, Media Monkey or MPD?

 

Much remains to be seen & heard from this NON-computer intended to supplant the computer in 'computer' audio.

 

It should be interesting. Clearly, if they can attract non computer savvy audiophiles over to the 'dark side', they will be quite successful.

 

 

"So, while USB is currently about the only way to enjoy high-resolution audio through your computer, in my opinion, it’s a short-term solution."

 

Huh?

 

 

clay

 

 

Link to comment

I wonder if we're seeing some confusion here with asynchronous SRC.

 

Paul M. is a great guy but he will be the first to tell you he's an analog engineer and some of this digital stuff is a bit beyond him.

 

Mac Mini 5,1 [i5, 2.3 GHz, 8GB, Mavericks] w/ Roon -> Ethernet -> TP Link fiber conversion segment -> microRendu w/ LPS-1 -> Schiit Yggdrasil

Link to comment

Hi Clay,

 

As you mentioned that the ULN-2 employs the asynchronous mode, I came across information at the RME website.

 

FireWire Audio by RME - Technical Background

 

All other manufacturers use dedicated all-in-one FireWire audio chips. As a result, their access to bugfixes and improvements is more than limited. Here is a small overview of currently used chips:

 

BridgeCo: used by M-Audio, Terratec, ESI, Edirol, Presonus, Apogee, Tascam.

 

Philips AV LLC: used by Motu and Hercules.

 

Upcoming: a new chip from Texas Instruments, co-developed or supported by Echo. Will be used in upcoming Echo and Mackie FireWire devices.

 

Upcoming: a new chip from TC, called Dice II. A few years ago TC have bought a company that produced non-audio FireWire chips. Now this chip, announced to be available more than a year ago, is said to finally arrive. If so, it will be used in upcoming TC FireWire audio interfaces for sure.

 

Upcoming: a chip from Oxford Semiconductors called OXFW970. Not as feature-packed as the other chips, but expected to be the cheapest one of all. It might cause another flood of very cheap FW audio interfaces in 2005.

 

Firewire DACs are not the same !

 

But I think the isochronous mode of Firewire can offer the same performance level of the async mode, depending on the implementation such as the RME's above, simply because of its high speed - FW100 FW200 FW400 & FW800.

 

Fire up that Wire! Get to know Apple's FireWire

 

High-Quality Video Digital Data = (30 frames / second) (640 x 480 pels) (24-bit color / pel) = 221 Mbps

Reduced-Quality Video Digital Data = (15 frames / second) (320 x 240 pels) (16-bit color / pel) = 18 Mbps

High-Quality Audio Digital Data = (44,100 audio samples / sec) (16-bit audio samples) (2 audio channels for stereo) = 1.4 Mbps

Reduced-Quality Audio Digital Data = (11,050 audio samples / sec) (8-bit audio samples) (1 audio channel for monaural) = 0.1 Mbps

 

 

 

 

If the async USB is a short-term solution, then RME should haven't released its flagship Fireface UC. IMHO, they are dropping Firewire from mobile pro audio !

 

BTW, the real benefit of Firewire is the ability to daisy-chain equipments for more channels with no performance degradation while the current USB architecture can't do this.

 

For 2-channel playback, why not async usb if it works very well ?

 

Link to comment

 

Dan,

 

I believe you're referring to Pauls' comment on the Asynchronous Clock?

 

Having seen the Asynchronous clock mentioned specifically in PS marketing literature with respect to the PWT, I don't think he's referring to ASRC. Actually, I don't recall hearing that 'feature' mentioned regarding PS Aadio DACs (a plus, in my view).

 

clay

 

 

 

 

 

 

 

Link to comment

Hi Clay,

 

Just so you know, PMcG does not spend his time on audio forums, or investigating all the latest gear out there, he is too busy working on product development, so his omissions above are not meant to obfuscate he is just ignorant of how many 24/96 USB DACs there are now. He was just talking about USB, not Firewire, and he would not consider pro audio products (which he uses i his video projects) to be suitable for his customers-he does not consider them at all as part of the high end consumer audio market.

When we talk about Async interfaces, like Firewire DACs and Async USB DACs we are talking about DACs which use a single, fixed frequency oscillator to clock the data, without having to reconcile the differences between multiple clocks like we have to do with SPDIF interfaces: this is exactly why the PerfectWave Transport and PerfectWave DAC use the I2S interface, and this system is "Async" in the same way as other products are. There is one (actually two, one for 44.1-88.2-176.4 sampling frequencies, and one for 48-96-192 frequencies) fixed frequency oscillator at the output of the solid state memory in the PerfectWave Transport, because this is connected to the PWD via I2S, the same clock is clocking the DAC, without any PLLs or SPDIF receivers being used, so the jitter level is kept low.

PS Audio's approach to computer audio has been that the networked approach is the best way to go, and most of their engineering efforts are going into making the PWD be the best network player it can possibly be. The Network Bridge will also be run "Async" as it will have a fixed frequency clock at its I2S output to the DAC.

You do not have to agree that the network player approach is the best way to go, but this is PS Audios' approach-they want to end up with a system where one just has the PerfectWave DAC with bridge connected to an ethernet, and outputting directly to a power amp, without a computer (separate box, noisy power supplies, etc.) in the listening room. What PS Audio is doing is trying to come up with a very elegant, user friendly system, that has the best sound possible, capable of playing back all resolutions of audio files.

 

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment

 

 

As you mentioned that the ULN-2 employs the asynchronous mode, I came across information at the RME website."

 

Actually, it's not clear that MH technically use 'asychronous' mode.

As GOrdon points out - but does not completely clarify - each manufacturer using Firewire must write their own drivers, so there is no known 'async' Firewire reference point. Metric Halo does use their own high quality clock to control flow of the incoming datastream, as I understand it. As was pointed out earlier in this thread - the focus on 'async' might be a bit misplaced, and what is important for the highest quality sound is a fixed oscillator (i.e. a single clock not trying to track another clocks signal).

 

I first heard Async applied to Firewire when Gordon began explaining his Async approach to USB, saying that he was emulating the Async approach used by the best pro audio firms. His main reason for NOT using Firewire, as I recall, was due to the need to write/update Firewire drivers.

 

"FireWire Audio by RME - Technical Background

 

All other manufacturers"

 

When any manufacturer starts a sentence with 'All others', I immediately stop reading. :)

 

 

"Firewire DACs are not the same !"

 

Totally agreed, and I don't think I've ever implied otherwise.

 

"But I think the isochronous mode of Firewire can offer the same performance level of the async mode, depending on the implementation such as the RME's above, simply because of its high speed - FW100 FW200 FW400 & FW800."

 

I believe Gordon refers to Bulk Mode as being the likely best way to describe how many manage the data when not referring explicitly to Async. I have no idea what that means, although I believe it's NOT mutually exclusive to isochronous.

Isochronous refers to the dedicated bandwidth feature of Firewire.

 

 

"BTW, the real benefit of Firewire is the ability to daisy-chain equipments for more channels with no performance degradation while the current USB architecture can't do this."

 

Their are numerous advantages of Firewire over USB, as far as I can tell. Peer-to-peer communications - without need to rely on the actual computer processor - is an often overlooked feature of Firewire what will become more relevant in the stripped down minimal processing computer systems. The only advantage I've ever been able to find (as the consumer) for USB is that there are more of them. :)

Personally, I've never viewed numerical strength AS evidence of superiority, as many seem to do.

 

IMNSHO, the rest of the technical community has balked at a superior approach brought to market by Apple/Sony again, and we all eventually suffer because of it, once again.

 

To your point above, I agree wholeheartedly. Right now I'm listening to a portable USB DAC on my Macbook Air (on which I type this). The Airbook has only a single USB port, which means I have to find a USB hub to connect the Amarra dongle, and an external (yet still portable) Mybook for additional music files that won't fit on my 128Gb SSD internal drive. With daisy-chaining, this wouldn't be a problem, but I can almost guarantee that not all USB hubs will work equally well.

 

"For 2-channel playback, why not async usb if it works very well ?"

 

I'm using Gordon's Async USB Streamlength now - in the $900 Proton - via Grado headphones. Sounds wonderful, and it's not even broken in.

 

But as I said above, there are so many advantages to Firewire, I will continue to use it as my main (read preferred) interface. The disadvantages are predominantly on the manufacturer's side - drivers mostly, and a complication with auto sampling rate changes (per I_S).

 

thanks for your post,

clay

 

 

 

Link to comment

Thanks so much for your many clarifications here, Barrows.

 

"He was just talking about USB, not Firewire, and he would not consider pro audio products (which he uses i his video projects) to be suitable for his customers-he does not consider them at all as part of the high end consumer audio market."

 

That's certainly his perogative.

 

"When we talk about Async interfaces, like Firewire DACs and Async USB DACs we are talking about DACs which use a single, fixed frequency oscillator to clock the data, without having to reconcile the differences between multiple clocks like we have to do with SPDIF interfaces:"

 

Agreed, I would re-title the thread if I thought it made sense.

 

"this is exactly why the PerfectWave Transport and PerfectWave DAC use the I2S interface, and this system is "Async" in the same way as other products are. There is one (actually two, one for 44.1-88.2-176.4 sampling frequencies, and one for 48-96-192 frequencies) fixed frequency oscillator at the output of the solid state memory in the PerfectWave Transport, because this is connected to the PWD via I2S, the same clock is clocking the DAC, without any PLLs or SPDIF receivers being used, so the jitter level is kept low."

 

okay, now we're getting closer. Thanks for clarifying this.

 

In addition to fixed clock (i.e. a pair of fixed oscillators) approach, it's my belief that they should be placed IN the DAC for highest available performance, but that could appear to be focusing on the 'wrong' thing by someone like yourself.

 

"PS Audio's approach to computer audio has been that the networked approach is the best way to go, and most of their engineering efforts are going into making the PWD be the best network player it can possibly be."

 

Networked players have a huge potential in this space, as it's frequently mentioned that when one talks about the advantages of Async Firewire and USB, that Networked players should be included.

 

"The Network Bridge will also be run "Async" as it will have a fixed frequency clock at its I2S output to the DAC."

 

Why put the clock on the other end of an HDMI cable? I don't see the upside to that. Many engineers suggest it's a problem, albeit competitors mostly.

 

"You do not have to agree that the network player approach is the best way to go, but this is PS Audios' approach-they want to end up with a system where one just has the PerfectWave DAC with bridge connected to an ethernet, and outputting directly to a power amp, without a computer (separate box, noisy power supplies, etc.) in the listening room."

 

Makes sense as a marketing approach for sure.

 

What is the user interface, i.e. the music player? Does it require a computer somewhere in the equation? Can the users' preferred music player be used?

 

 

Thanks much for your response, as always it is quite helpful.

clay

 

Link to comment

>What is the user interface, i.e. the music player? Does it require a computer somewhere in the equation? Can the users' >preferred music player be used?

 

I believe PS Audio will have its own music player. Who knows, it may be great; Paul has said that they will make it better for classical music than we are used to. Still, it will be proprietary from a relatively small player, and then you're locked in, right?

 

Mac Mini 5,1 [i5, 2.3 GHz, 8GB, Mavericks] w/ Roon -> Ethernet -> TP Link fiber conversion segment -> microRendu w/ LPS-1 -> Schiit Yggdrasil

Link to comment

 

Dan,

 

thanks for the suggestion.

 

Having spent some time at the site back when the PWD was introduced, I find the PS audio forum to have way 'too much koolaid'.

Maybe it was due to the recent release, but it was very clear that no one there wanted anything to do with questions that were even remotely critical. Heck, even a fanboy like Timequest never get an answer to the 2pS jitter question.

 

Besides, we have Barrows to give us the unadulterated version, without the sugar, for which I am very grateful.

 

But, you're right I should go there to at least discover the features of the first network player to hold ANY interest for me. If Paul gets this right, the others may find themselves in trouble, in my opinion, although a lot still hinges (apparently) on the hitter performance via HDMI cable with the clock in the Bridge.

 

Other than the Metric Halo forum, the PS forum is the only audiophile manufacturer's forum I've ever (continued to) read after the first visit, that I can recall. I've only seen more fawning at the Nelson Pass group at DIYAudio, which is well deserved in my opinion.

 

aloha,

clay

 

PS, are you trying the J2?

 

 

 

 

Link to comment

This is the first reason why people play music from a computer.

 

It would be very hard to choose songs from the list of your music files stored on your 2TB SDXC card inside a jitter-free stand-alone music player !!

 

The second reason is that computer storage is also easily expandable for your growing music collection.

 

So, it is why we need a "perfect" way for sending wave files from a computer to feed a DAC.

 

 

Link to comment

It would appear that the newsletter from Paul McGowan is a very well though out document - if purely from the marketing point of view.

It basically reads: "Well, yes, we agree Asynch USB is the best way of doing USB, but no, we don't do it and won't do it, but it doesn't matter because just hang on and everything will be fantastic in the future with networked audio".

 

Which is fair enough, and this type of approach is one I much prefer to "Asynch interfaces are all hype, with these (fake) drawbacks" etc., as mentioned previously. He obviously isn't going to mention the fact that architecture of the system with the bridge has the DAC clock in the wrong place ( in my opinion ), or that the bridge still hasn't appeared, or that even when it does appear, it's in the same space as e.g. the Naim HDX, Linn streamers etc. Again, I have no problem with this, just trying to keep a little bit of perspective.

 

I've also read on here that a "memory player" type approach is the way to go - the problem here, (as with all engineering) is the trade-offs you have to make. In this approach, you are relying on one manufacturer for everything - UI, file type support. Additionally, you are adding more complexity inside the DAC - you start adding the IP protocol stack, codec handlers etc, and you start getting something looking rather like a PC, which potentially isn't the ideal place for your sensitive clocks and analogue circuitry.

 

The computer audiophile market is still settling down, and I personally suspect that the ease of use factor will be the one driving the market rather than super-high sample rates, but if enough manufacturers can sneak in the higher-res stuff, then that's a win-win, as far as I'm concerned....

 

Just to clarify: In the networked audio scenario, via UPnP ( which I believe is the bridge ), the architecture is as follows:

UPnP Server - exposes it's colection of media ( this can be WMP on a PC, Twonky on a NAS )

UpnP Renderer - "renders" the media ( i.e. a DAC ) - it reads the file from the server and plays it

UPnP control point - tells the renderer what file to play from the server.

 

In the case of the bridge, the bridge + PWD form the renderer... as I say, from an architectural point of view I'd prefer the DAC clock in the DAC rather than the bridge, but I'm an idiot.

Additionally, it is up to the server how the music is catalogued, and the hierarchy which is presented to the user - NOT the renderer or control point, which I guess is why they're talking about making a NAS...

 

your friendly neighbourhood idiot

 

Link to comment

With the PWT, the clock signal is sent to the DAC on its own cable run: the only potential here for additional jitter are the losses from the cable itself, these losses are fairly low, and are no different than the losses which would occur when using a separate master clock, ala dCs, esoteric, etc.

A network player requires that it run its own player software and its GUI, these are big development issues, and are a major reason one does not see network players from a lot of high end audio companies. There has been a fair amount of criticism of the Linn players, claiming that the interface is clunky at best, especially when compared to something as slick as Itunes. I am a big fan of the sound of the Linn Klimax DS though, and could live with the interface if I could afford one.

The PS Bridge is going to be inside the DAC, so the clock is going to be right there, so no worries about jitter losses due to clock location, this is the same as Firewire or an Async USB receiver: the fixed frequency clock clocks the data stream out of the buffer of the receiver and into the DAC. The beauty of an audio company building the entire product like this means that they can control the network receiver, which is essentially a small computer, and can build the power supply, board layout, and shielding so as to assure there is no interference with the DAC and analog output stage.

Having heard the Linn DS I am certain that it is possible to build a network player that offers state of the art sound in a single chassis-whether or not the PS PWD/bridge will achieve great sound is yet to be seen. I have not heard a single bad review, or even posted opinion, on the sound of the Linn Klimax DS yet, but there is always a first time.

 

SO/ROON/HQPe: DSD 512-Sonore opticalModuleDeluxe-Signature Rendu optical with Well Tempered Clock--DIY DSC-2 DAC with SC Pure Clock--DIY Purifi Amplifier-Focus Audio FS888 speakers-JL E 112 sub-Nordost Tyr USB, DIY EventHorizon AC cables, Iconoclast XLR & speaker cables, Synergistic Purple Fuses, Spacetime system clarifiers.  ISOAcoustics Oreas footers.                                                       

                                                                                           SONORE computer audio

Link to comment

I thought the bridge was another box, rather than ( as it would appear ) an add-on for the PWD - this would go a long way to reassuring me about the architecture...

However, the whole marketing thing rears it's ugly head again... on the website, it does state the PWD acts as a music server, with a network input, etc, and it's only when you dig further does it say "with optional network bridge, available summer 2009". I understand that marketing and engineering often don't agree with timescales in particular, but even so... the bridge is still "a couple of months away" ( November newsletter ).

 

I've promised not to go on about clocks over external links, but the devices you mention ( dCS, Esotetic ) use PLLs rather than the raw clock. I may start another thread at some point with some reasons as to why some companies use PLLs, but not today... since CG may be about maybe he would contribute (please?)

 

As for one manufacturer being able to optimise things because they do more in one box, I'd agree to a certain point, but surely the same argument could be made with regard to whole systems - I've certainly heard it said you want everything ( source,amp,speakers ) from the same manufacturer ( e.g. Naim, Burmester, Linn ), but I've always regarded Hi-Fi as being more open for mixing by users, and the current computer audiophile trend seems to bear this out - look at the mass debates about Amarra vs iTunes vs Foobar, for example...

 

your friendly neighbourhood idiot

 

EDIT

I am really, really not singling out PSAudio here - as I've said, they're marketing stuff is really not that outrageous in comparison with a lot of stuff, and by all accounts it sounds good. Just having barrows adding to the conversation will make me ask questions...

 

 

 

 

 

 

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...