Phison Audio PD2 Preamp/DAC

[Mivera Audio]

They do not add noise, unless the DAC or ADC is integrated in the DSP. The rest is in the digital domain. If as I am working on are choosing a DSP you just have to be sure that the MAC run with enough bits.


Sent from my iPhone using Tapatalk

But do they not emit EMI? On another thread on Computer audiophile people were talking about it being critical where they are placed to avoid interference from other sections of the DAC. I have a hard time believing that a digital signal could pass all the way through a SHARC chip and have absolutely no jitter and noise introduced what so ever. Especially if they are working hard processing advanced algorithms.

 

[SonnyDK]

All processors does emit EMI, but that is something you take care of using shielding and circuit layout..

Jitter will always be present, but if you feed your DSP with a reference with the I2S or DSD in slave mode of the clock that also feeds the DAC and reclocking then the jitter will be down to circuit layout and the clock and clock distribution you use.

The main thing about FPGA and DSP is that the calculation can be controller by interrupt generated by the I2S or DSD that runs in slave mode. No OS to screw up things.

 

[Mivera Audio]

All processors does emit EMI, but that is something you take care of using shielding and circuit layout..

Jitter will always be present, but if you feed your DSP with a reference with the I2S or DSD in slave mode of the clock that also feeds the DAC and reclocking then the jitter will be down to circuit layout and the clock and clock distribution you use.

The main thing about FPGA and DSP is that the calculation can be controller by interrupt generated by the I2S or DSD that runs in slave mode. No OS to screw up things.

Yes I understand there's ways to minimize the jitter and EMI. All I'm saying is if they aren't there at all, you don't have to worry about it at all. Most people use some sort of computer as a server anyways to connect to the DAC. If all of the processing that a DSP can do, is done on the connected server, no additional noise, jitter, EMI etc will be sent from the computer at all opposed to if the DSP wasn't processed on the computer. And the DSP chips aren't required to be in the DAC at all this way. This isn't a conventional approach to doing things of course, but if you look at what the guys at sound galleries in Monoco are doing with their fancy server running Roon/HQplayer combined with the T+A DAC 8 DSD, it's the same thing. Have you read the feedback on that? Perhaps you should go see their demo in Munich in May at the BMW Welt center.

 

[Mivera Audio]

The folks at Merging are masters of audio DSP. They have been in the business of audio DSP for 20 years. They used to use Sharc DSP chips for many many years for their DSP boards. A few years ago they switched to PC based DSP using Intel processors. Watch this video and you will see what they have to say about this approach.

 

[SonnyDK]

I know sound Galleries very well. I have spoken with Edward Hsu before. And i do know there work.

But it is not the question or discussion here. It is the use of DSP that would introduce noise to signal in the digital domain. Nothing more nothing less.

 

[Mivera Audio]

I know sound Galleries very well. I have spoken with Edward Hsu before. And i do know there work.

But it is not the question or discussion here. It is the use of DSP that would introduce noise to signal in the digital domain. Nothing more nothing less.

Well you may know more about that than me, but to me it's logical to think that a 1-2cm copper PCB trace will generate far less noise/EMI/jitter than a Sharc DSP chip.

 

[FlexibleAudio]

Are you talking about the filters? If so its all about the algorithms used. Put it this way. The algorithms that MSB uses in their DSP chips could run on a quad core I7 Intel processor at probably 1-2% CPU load. But there's no way on earth that HQplayer's best algorithms could run on the DSP chips. Not only that, you have all the extra circuitry to run through when you use DSP chips. DSP chips are not 100% noise and jitter free. If you are using a computer as a server anyways, you are running the data through it regardless. A well implemented USB or Ethernet interface will block all noise from a connected computer. If you look at the PD2's DAC board for example, you'll notice that there's no FPGA's or DSP chips. This allows the data path to be very short with low noise and jitter. I think this is 1 reason it sounds so good.

Now if you read the 6 moons review you will see that Srajan says he prefers "PCM as PCM" well saying that proves that he has no idea how a modern SDM DAC chip works. The only DAC's that process "PCM as PCM" are R2R DAC's like in the MSB. With his experiment using the lousiest filters/modulators in HQplayer, all he is saying is he prefers the SRC/SDM built into the AKM chip, over the particular SRC/SDM combination chosen in HQplayer. That's like giving someone a set of speakers to audition with a blown midrange and expecting a positive result. But the worst part is 99% of people reading that review who don't know any better, are going to walk away thinking that the PD2 is lousy at DSD.

Ok Blizzy,

Help me understand this a bit more. If I want to get files in their respective native format (not converted, upsampled, etc. ) to a dac with sound quality being my absolute and only objective (interface, etc. don't matter), is not the MSB solution optimum. Your statement bolded above has proven to be very difficult to execute as it relates to USB given the grounding issues not inherent in ethernet. So again with that said, even if executed perfectly as you profess is achievable, would this still only be equal to but not superior to the MSB topology? The whole point is to NOT use a computer as a server because they are sub-optimum.

 

[Mivera Audio]

Ok Blizzy,

Help me understand this a bit more. If I want to get files in their respective native format (not converted, upsampled, etc. ) to a dac with sound quality being my absolute and only objective (interface, etc. don't matter), is not the MSB solution optimum. Your statement bolded above has proven to be very difficult to execute as it relates to USB given the grounding issues not inherent in ethernet. So again with that said, even if executed perfectly as you profess is achievable, would this still only be equal to but not superior to the MSB topology? The whole point is to NOT use a computer as a server because the are sub-optimum.

MSB did a phenomenal job on the DAC you have. For $60000+ or whatever it cost with that fancy clock, I think this should be expected. However there is more ways to skin a cat. If I joined the team at MSB, this is what I would encourage them to try:

-Build a complete system, server and all, and use Interval zero's RTX64 real time OS on the server with a quad core I7 Skylake Intel processor to handle the DSP.
-Ditch the Sharc chips in the DAC.
-Run the Roon core on the server so the best GUI on the planet, combined with Tidal streaming could be run on an Ipad
-Use Ravenna instead of UPnP/Blackfin DSP chips in the DAC's interface.

If they took that approach, I believe they could make an even better sounding system, and have the best GUI as well.

 

[FlexibleAudio]

MSB did a phenomenal job on the DAC you have. For $60000+ or whatever it cost with that fancy clock, I think this should be expected. However there is more ways to skin a cat. If I joined the team at MSB, this is what I would encourage them to try:

-Build a complete system, server and all, and use Interval zero's RTX64 real time OS on the server with a quad core I7 Skylake Intel processor to handle the DSP.
-Ditch the Sharc chips in the DAC.
-Run the Roon core on the server so the best GUI on the planet, combined with Tidal streaming could be run on an Ipad
-Use Ravenna instead of UPnP/Blackfin DSP chips in the DAC's interface.

If they took that approach, I believe they could make an even better sounding system, and have the best GUI as well.

To me, that's gunna make a racket. The only way it makes sense to me is if you are putting interface and format manipulation over sound quality in your priority list, but what do I know

 

[Mivera Audio]

To me, that's gunna make a racket. The only way it makes sense to me is if you are putting interface and format manipulation over sound quality in your priority list, but what do I know

What makes you think that? Better algorithms can be run on the server using an intel I7 quad core processor, and the RTX64 real time OS vs the DSP chips, and an even shorter signal path can be implemented in the DAC. UPnP was never made to be a high end audio solution. Both Jussi and Roon hate it for several reasons pertaining to sound quality. This is because a bunch of additional processing is required on the receiving end. Jussi's NAA, and the Roon RAAT system is far superior. They were designed from the ground up as a superior alternative to UPnP, specifically for high end audio, overcoming all of the deficiencies of UPnP. Same with how Ravenna is done. And the NAS you use as a server, is a computer you know. Just like a regular PC only uses a low powered CPU, and a Linux based OS. So you are not avoiding a computer based server from being in the picture in your system right now.

 

[FlexibleAudio]

Blizzy-poo,

Is that triceratops or stegosaurus? I am no expert in this stuff but I still think its inferior to ethernet direct to i2s and the "real" reason designers are stuck using it (and hence try to argue its pretty snazy) is cuz they haven't developed an eloquent way to get dsd through a direct i2s implementation like msb. My Femto 33 controls all clocking in the i2s input. Its a fairly good clock and it gots a fairly good lps. No matter how much you clean up a nasty ground and icky packet noise its hard to argue its better than a connection that is squeeky clean from the start. (Of course I plan to use ethernet glass with a linear ps.) Save the usb stuff for a museum.

Now don't bite, you promised...(I am just haven fun and trying to catch up on this stuff with the deep thinkers.)

What makes you think that? Better algorithms can be run on the server using an intel I7 quad core processor, and the RTX64 real time OS vs the DSP chips, and an even shorter signal path can be implemented in the DAC. UPnP was never made to be a high end audio solution. Both Jussi and Roon hate it for several reasons pertaining to sound quality. This is because a bunch of additional processing is required on the receiving end. Jussi's NAA, and the Roon RAAT system is far superior. They were designed from the ground up as a superior alternative to UPnP, specifically for high end audio, overcoming all of the deficiencies of UPnP. Same with how Ravenna is done. And the NAS you use as a server, is a computer you know. Just like a regular PC only uses a low powered CPU, and a Linux based OS. So you are not avoiding a computer based server from being in the picture in your system right now.

Ok let me try to comment as best I can:

1) Regarding me "already using a computer," while technically true, its a stretch on your part to point to my NAS and compare it to all the crud your I7 is gunna do to SQ. Spitting the files out on ethernet is a whole different thing than all the burnin-and-churnin you are talking about in a server let alone the fact that when you are done all you got left to git the bits to the dac is USB (ouch). Also, as I already said above (bold) the ethernet would be glass in my example.

2) Regarding running "better algorithums," my entire premise is based on an assumption I am not doing this so the point is moot. I want native files hittin my dac as squeeky clean (quiet) as is humanly possible (or super humanly if you got some other tricks). The real beauty of the MSB approach is the understanding that for those in pursuit of absolute purity there is a way to eliminate the high price paid for a snazy interface and file processing and in turn achieve the last degree of SQ. (All that said, If I really wanted the processing I could just do it with Saracon instead of on the fly with Jussi and keep them monsters on the nas.)

3) Of course UPnP is famous for all of the travails incumbent on being the "least standardized" Standard ever created. It is glitchy, snitchy and all that stuff but I have never heard Jussi (or anyone) pine about it having a drawback to SQ. Once its working it works. Although getting it going ca be a be-atch some time. I am not sure how it would even be possible for the UPnP to even have a negative effect on SQ; maybe you can enlighten me on that one.

Just lookin to learn. Thx.

 

[Mivera Audio]

Ok let me try to comment as best I can:

1) Regarding me "already using a computer," while technically true, its a stretch on your part to point to my NAS and compare it to all the crud your I7 is gunna do to SQ. Spitting the files out on ethernet is a whole different thing than all the burnin-and-churnin you are talking about in a server let alone the fact that when you are done all you got left to git the bits to the dac is USB (ouch). Also, as I already said above (bold) the ethernet would be glass in my example.

2) Regarding running "better algorithums," my entire premise is based on an assumption I am not doing this so the point is moot. I want native files hittin my dac as squeeky clean (quiet) as is humanly possible (or super humanly if you got some other tricks). The real beauty of the MSB approach is the understanding that for those in pursuit of absolute purity there is a way to eliminate the high price paid for a snazy interface and file processing and in turn achieve the last degree of SQ. (All that said, If I really wanted the processing I could just do it with Saracon instead of on the fly with Jussi and keep them monsters on the nas.)

3) Of course UPnP is famous for all of the travails incumbent on being the "least standardized" Standard ever created. It is glitchy, snitchy and all that stuff but I have never heard Jussi (or anyone) pine about it having a drawback to SQ. Once its working it works. Although getting it going ca be a be-atch some time. I am not sure how it would even be possible for the UPnP to even have a negative effect on SQ; maybe you can enlighten me on that one.

Just lookin to learn. Thx.

All of the noise created from the I7 processor in the server is a moot point. I would be using fibre Ethernet as well with the Ravenna interface. Noise doesn't pass through the glass and plastic very well. And don't think that's there's no processing required by the blackfin chip in the MSB interface. The reason that Jussi's NAA and the Roon RAAT systems were created was to avoid this layer of processing. With NAA and RAAT, all of the heavy lifting is done on the server end.

Regarding the better algorithms, why do you think they are using the Sharc DSP chips in the first place? Why do you think they talk about the powerful processing capabilities of the Sharc chips? It's because more powerful DSP, makes better filters possible. The quality of the filtering is only limited by the power of the DSP. By having a 100x more powerful DSP engine, better algorithms can be preformed.

And as far as the offline upsampling with Saracon, tests have already proven Jussi's algorithms are superior. A better choice is Merging's Pyramix. But if you do buy the $3500 software, and offline convert your entire PCM collection to quad DSD then you need to take up on average 8gb of hard drive per album. And please explain to me how you can offline upsample a streaming service like Tidal? The performance with Tidal is one of the biggest benefits for me of using Hqplayer to upsample on the fly to quad DSD. And if you think streaming services aren't the future, you are dreaming.

And yes Jussi has gone on for years complaining about UPnP and the bottleneck for sound quality. The Blackfin DSP chip Ethernet interface endpoint was a good system circa 2014-2015. But better ways are in the works now. Ravenna, NAA, and RAAT are 3 examples. We will see more and more implementations using them in the near future. dCS has just implemented the RAAT system from what I hear.

 

[FlexibleAudio]

Okee dokee Bliz. So the new thing is you can output hqplqyer on ethernet???? That is cool.

 

[Mivera Audio]

Okee dokee Bliz. So the new thing is you can output hqplqyer on ethernet???? That is cool.

No it's been around for years. Only people have just started listening to Jussi about it's superiority compared to UPnP recently. The Roon RAAT system is based on Jussi's NAA system. That's what my whole "Superstream" on WBF uses. It's also what the streamer I will be sending my clients for free with the PD2's uses as well. It won't be a $3000+ option, it will be free

 

[FlexibleAudio]

So with your server I kin crank up HQP to do all its fiddlin with the bits, enjoy all the benefits of whatever the smokin interface du jure happens to be (Roon, et al) and then just shoot the bits over to the dac through ethernet glass. That is pretty wiz bang. Why the heck were you splaining all about a usb connection earlier if you got that goin on?

 

[Mivera Audio]

So with your server I kin crank up HQP to do all its fiddlin with the bits, enjoy all the benefits of whatever the smokin interface du jure happens to be (Roon, et al) and then just shoot the bits over to the dac through ethernet glass. That is pretty wiz bang. Why the heck were you splaining all about a usb connection earlier if you got that goin on?

The USB interface is what the PD2 uses now. The PD2 only has an USB, and SPDIF interface's right now. But as I explained, it's the best implementation I've ever seen for a USB interface. However my server is compatible with any "Audio over IP" protocol, and USB implementation.

Just to be clear we are talking about 2 different products from 2 different manufacturers. The Phison PD2 is a Phison product, made in Denmark by brothers Sonny and Phillip Anderson. The server I have in the works is a Mivera Audio product built in Canada by me. However when used together, they are a match made in heaven. The free streamer I'm going to send with the PD2 is a Mivera Audio product as well. And the Ravenna implementation I've been talking about, is also a Mivera Audio venture. Phison is not on board with this system at all.

 

[Mivera Audio]

Here's some info on the Roon RAAT audio over IP protocol from the Roon CTO:


Architecture
Well-architected systems give better user experiences. They work better in the short and long term, and they surface fewer unexpected limitations down the road as the world changes.
AirPlay started its life as a feature of the AirPort Express. It evolved into an audio distribution system a few years later. It is hobbled by trying to fit into the performance envelope of the embedded devices of yesteryear, and it's cobbled together--a mishmash of hacked up versions of several well-known protocols, with very little coherence to the overall system design. It looks like what it is: an overgrown feature masquerading as infrastructure. It's stretched pretty thin, at this point, and it hasn't evolved in a long time.
RAAT has an advantage: it is 10-30 years younger than the bits+pieces that make up AirPlay. We can see not only where the world has gone, but, one level up, what types of change have taken place. We are in a great position to do a better job.
Also worth mentioning: designing network protocols for transporting audio is a core competency of ours. I did the protocol design for RAAT, but this isn't my first time, it's my third. The last protocol I built handles all of the networked audio distribution for Meridian's products, and the one before that handled audio distribution for Sooloos products up until about 2010. There is no substitute for the experience of actually putting something like this into production in the real world.
RAAT is plumbing. It gets the audio from point A to point B without screwing it up, and without bringing limitations to the table that might compel the software/hardware on either side of it to screw things up. It's an enabling technology for "doing things right" everywhere else in the system. Otherwise, it shouldn't get in the way.
Design Goals

• Support all relevant audio formats today and for the foreseeable future. We don't publish a list of formats that RAAT supports because it is not the limiting factor. RAAT is already built to handle multi-channel, and 32bit content. Once Roon supports them, RAAT will too.
  
• Stable Streaming over Ethernet and WiFi networks. We take this for granted in 2016, but it's easier-said-than-done, and a huge set of implementation choices are driven by this requirement.
  
• Modest endpoint hardware requirements. This means endpoints don't have to handle expensive DSP or content decoding--that will happen on the server. This means that many existing devices can add support for RoonReady without changing the hardware.
  
• Audio devices must own the audio clock. Many other protocols get this wrong, including AirPlay. It's not possible for two clocks to agree perfectly. Letting the DAC control the pace of streaming removes the need for a clock-drift-compensation mechanism that is bound to increase cost, decrease quality or both.
  
• Tight playback synchronization suitable for multi-room listening. There's a careful line to walk here. If we demand ultra tight (1-10us) sync, it becomes impossible to implement the system on existing/unspecialized/heterogenious hardware platforms. We shoot to be within 1ms (and under ideal circumstances often much better), which is more than adequate for multi-room listening.
  
• Support for new streaming services, file formats, DRM schemes, etc can be supported without firmware upgrade. In fact, the only reason an upgrade should be required is to fix a low-level bug, or to access more hardware functionality. This is really important. Not all partners/hardware have easy firmware update paths that can be done at home. Our acceptance of this reality has deeply influenced RAAT's design. Just as with Google's Cast devices, the majority of the business logic is delivered to the device at run-time as a script. This means that we are capable of completely re-designing the audio streaming and buffering logic without updating device firmware. This is absolutely critical, since most of the bugs + evolution in a system like this relate to networking, not audio. Other than Cast, we are unaware of another system that is this flexible.
  
• Cheap to implement, and easy to distribute. No patented technologies involved. No requirement that manufacturers use technologies that are subject to export restrictions. And Roon provides provides a high quality, portable reference implementation as a base for customization instead of a pile of documents describing a network protocol.
  
• Provide a great user experience. This means no stupid 2s delays when touching transport controls (looking at you, AirPlay). It means no too-simple-to-be-good approaches to zone synchronization (looking at you, squeezebox). It means no artificial stream format limitations. It means that the system is flexible enough to allow processing in the server or the endpoint. It means that volume control and source selection works right whenever possible.
  
• Promote Honesty regarding what is happening to the audio. RAAT is tied to Roon's signal chain feature. We work with manufacturers to make sure that potentially destructive processing stages like software volume controls are exposed to interested users, and that processing isn't being concealed or hidden.
  
• Enforce high quality user experiences via a certification program. User experience is another core competency for us. We are actively pushing hardware companies to make better user experiences by iterating with them on the product before allowing them to be released. We require parity between RoonReady integrations and other audio protocols offered by the devices, ensuring that Roon support does not become a second class citizen. Another requirement of the certification program is that hardware manufacturers leave devices with us long-term for support and QA purposes.
  
• Two-way control integration. Artwork and now-playing information can be displayed on hardware devices. Front-panel controls and IR remotes can control Roon via the device. Volume controls on device front panels can be kept in sync with Roon. If you're talking to a device that has multiple inputs, and start music in Roon, the input automatically switches to Roon's input. Anyone who's used Roon's Meridian integration knows the value of this set of capabilities.
  
• Deeply extensible protocol. We've placed many extension points in the hardware protocol, and in the interfaces between the RAAT implementation and the hardware-specific code. This allows us to easily support more functionality in the future. We fully expect to learn of more use cases as the breadth of hardware that we are supporting grows, and the protocols are designed to get out of the way and scale gracefully.
  
• No support for under-specced platforms or un-proven network stacks. RAAT is built to evolve over time. We continue to improve the network protocol. We might decide to change the buffer size requirements on the device to increase stability. We might decide to build a second network protocol optimized for streaming over WAN, or something else like that. We give the same advice for users of Roon as we do to manufacturers building RAAT-based products: under-specced systems lead to bad user experiences; hardware is cheaper than ever and getting cheaper all the time; don't over-economize if you want the best result.

 

[FlexibleAudio]

The USB interface is what the PD2 uses now. The PD2 only has an USB, and SPDIF interface's right now. But as I explained, it's the best implementation I've ever seen for a USB interface. However my server is compatible with any "Audio over IP" protocol, and USB implementation.

Just to be clear we are talking about 2 different products from 2 different manufacturers. The Phison PD2 is a Phison product, made in Denmark by brothers Sonny and Phillip Anderson. The server I have in the works is a Mivera Audio product built in Canada by me. However when used together, they are a match made in heaven. The free streamer I'm going to send with the PD2 is a Mivera Audio product as well. And the Ravenna implementation I've been talking about, is also a Mivera Audio venture. Phison is not on board with this system at all.

Good grief now I am lost. We just had a multi-post exchange about a specific subject and you explain your point, I confirmed my understanding of your point, and then you say yes "that's correct" with one minor exception-- my point isn't true.

Let's just stay with the world we live in here and now. I will ask simple yes/no or true /false questions and lets see if I can understand.

Currently, the DAC you sell (PD2) has only USB and SPIDF inputs? (I understand the answer is true.)

You hope to have a Server to sell that will use Audio over IP via Ravenna but currently the dac you sell is not compatible with your server. (I understand the answer is true.)

Accordingly your server is left sending DSD to Dacs (the PD2 or otherwise) via USB. (I understand the answer is true.)

So if these are all true, we are back to were I was when I asked you my question in post #96--

Blizz, As a a purely theoretical matter, talking strictly about sound quality (NOT INTERFACE), is it not true that the the best this server could sound would be equal to but never better than the MSB solution? If not can you explain why?​

In other words (setting aside upsampling and/or conversion) if everything in USB is executed perfectly the best it can do as far as SQ is concerned is to equal an ethernet-to-I2s (direct via Audio over IP). TRUE or FALSE????

Now if/when you get your RAAT crankin and the world is full of DACS with raat compatible ethernet inputs to boogie with it, like I sad before, that will be pretty wiz bang, but we ain't there yet. TRUE or FALSE???

 

[FlexibleAudio]

Hey Blizzy,

One more thing, the reason I feel the way I do is cuz I spent all last fall lookin for a solution that would get hqp into a dac through something other than usb and couldn't find it so I bought what was best at the time the MSB renderer. (I talked to Jesus, dac peddlers and such.) I bought the renderer thinking some really smart young feller would come along and skin this cat. Now git 'er done.

 

[Mivera Audio]

Good grief now I am lost. We just had a multi-post exchange about a specific subject and you explain your point, I confirmed my understanding of your point, and then you say yes "that's correct" with one minor exception-- my point isn't true.

Let's just stay with the world we live in here and now. I will ask simple yes/no or true /false questions and lets see if I can understand.

Currently, the DAC you sell (PD2) has only USB and SPIDF inputs? (I understand the answer is true.)

You hope to have a Server to sell that will use Audio over IP via Ravenna but currently the dac you sell is not compatible with your server. (I understand the answer is true.)

Accordingly your server is left sending DSD to Dacs (the PD2 or otherwise) via USB. (I understand the answer is true.)

So if these are all true, we are back to were I was when I asked you my question in post #96--



In other words (setting aside upsampling and/or conversion) if everything in USB is executed perfectly the best it can do as far as SQ is concerned is to equal an ethernet-to-I2s (direct via Audio over IP). TRUE or FALSE????

Now if/when you get your RAAT crankin and the world is full of DACS with raat compatible ethernet inputs to boogie with it, like I sad before, that will be pretty wiz bang, but we ain't there yet. TRUE or FALSE???

1: Yes as explained already, the PD2 only has SPDIF and USB input

2: As explained in my previous post, my server is compatible with everything. USB, Ravenna, RAAT, NAA etc.

3: My server can send PCM via RAAT or NAA to a max of 32/768, and DSD 1024. With USB, max output support is 32/768 PCM and DSD 1024. With Ravenna max PCM currently is 24/384 PCM and DSD 512.

As far as USB vs the finest audio over IP protocols go, it will be splitting hairs trying to beat what Sonny has done with the PD2 USB implementation. As I said its the best I've seen in any DAC at any cost.

My server can do RAAT to any RAAT compatible DAC right now. As well as all the formats I listed earlier. This is today, no need to wait.