@alekz We will sell refurbished PWDs we take in on trade, for sure. It’s the only way we make this work financially. The investment in this 7 year design project has been, well, big. @-)
@edorr Yes and it’s now a real toss up. But for now the preamp stays in. Mostly because it’s a lot easier to do A/B testing!
@stevem2 Indeed, there’s no sample rates and there will be some useless buttons.
@stevem2 Indeed, there's no sample rates and there will be some useless buttons.
Paul. I am still a bit confused. For those of us who decide to have our PWD MKII upgraded to the DirectStream DAC, will our DACs, when upgraded and returned look identical to the new DirectSteam units being shipped and will they be re-boxed in a new DirectStream container?
@tedsmith
Thanks for the input Ted and welcome to the forums. Sounds, pun intended, exciting to say the least 
How many inputs and of what flavor will the DirectStream have?
@stevem2 Indeed, there's no sample rates and there will be some useless buttons.
So a new DS will have the same 'useless' buttons since the cases are unchanged or is it different ?
I was talking about buttons on the remote. I’m sure the front panel touch screen will be reprogrammed to fit the DirectStream’s functions. I don’t know if new DirectStreams will come with the same remote as the PWD (with the useless buttons) but it wouldn’t surprise me (one way to save costs).
magicknow, my impression was that the inputs stay the same but I could be wrong.
@magicknow
The same as the PWD 2 x I2S (over an HDMI connector), S/PDIF (coax), AES/EBU, TOSLink, USB and Bridge.
@rogerdn
Yep, as stevem2 said: the UI will be familiar, but simpler. The AN1, AN2, Filter and SR buttons on the remote won’t have anything to do.
Sorry to pester you PS guys… The forums are certainly buzzing today!
My questions: 1) will the upgrade and trade-in pathways be available to international buyers?
2) has the i2s over HDMI implementation changed in any way?
3) is nativeX mode now kaput/irrelevant?
Congratulations on the new product.
Just asked my dealer to put me in the queue for a kit, looking forward to PSF
@stereophilus
2) The master clock signal is ignored (we don’t sync to the incoming clocks, we just sample them, so the master clock is irrelevant). The I2S inputs also can be used to send raw single or double rate DSD as a clock, a left bit, and a right bit / sample.
3) NativeX is irrelevant: there is no asynchronous upsampling going on and the DAC always finds the input sample rate and, in essence, is locked on all inputs all of the time. Then which ever input is selected is synchronously upsampled, …
In theory, should all decent CD transports sound the same through this new DAC?
@st50maint
The DAC should sound the same, send it the bits, it’ll deliver the music. From a given transport it’ll sound the same with whatever connections are used (if they have the bandwidth.)
That said my personal experience is that transports are some of the worst offenders with the noise they inject back into the system thru the power cords and possibly with EMI if they have brushes in their motors. I keep my transport 10’ from the rest of the system and plugged into it’s own dedicated line and I use TOSLink (or AT&T glass for my EMM Labs DAC6e) whenever I can. So in practice you may need to be careful with your transport setup no matter what DAC you have.
Hi Ted
A big welcome to a welcome member.
Following steriophilus’ question does that mean the lens buffer is totally gone?
When using Bridge-1 we would still have it’s lens?
Gordon
Is the PWT putting noise over the HDMI. And do we have to put our PWT 10 feet away too?
Al
@Gordon
I’m not totally familiar with all of the PS Audio nomenclature so I might miss the intent of your post. There is no explicit lens in the PS Audio sense, but the FPGA has a similar mechanism:
The FPGA samples all inputs without syncing to their clocks. I.e. it treats all inputs the same. It interprets the bits it finds like a human would on a scope, i.e. by local context but not in real time. The bits are packaged up according to the protocol (I2S vs AES/EBU, etc.) and put into a big FIFO. The FIFO is read based on the FPGA’s version of system clock and retimed when it gets to the analog card using the very precise system clock. I don’t really know what the bridge does internally, it doesn’t matter if it gets the right data over I2S to the FPGA.
tedsmith said: The master clock signal is ignored (we don't sync to the incoming clocks, we just sample them, so the master clock is irrelevant).
Conceptually, this makes a great deal of sense. Very cool.
@ALRAINBOW
The noise over HDMI is not likely to be a problem: it uses terminated differential signals which are inherently low noise and the HDMI cable has a solid ground. The issue is whether there are ground loops in your system and how your system responds and that is DAC/Transport independent.
My point when I mentioned keeping the transport away was that many people assume that the DAC itself or transport jitter are the worst problems with a transport/DAC pair and overlook other possible problems. I’m just trying to point out that most people would benefit from thinking about the transport’s power, etc. This is independent of what DAC they may use and is just good “transport hygiene”.
We take some pains to galvanically isolate inputs to the DirectStream DAC so there are as few problems as possible. And where we have to have a ground connection we make it as solid as possible to lessen any effects from system wide ground loop currents.