DS vs DS Mk II

I thought I’d start a series of posts about what you might expect with the DS Mk II. I’ll probably post something every day or two for a while here.

I also would like to keep this thread reasonably clean so people don’t have to wade thru thousands of posts to get an overview of the differences.

There’s already a more detailed thread about the Mk II where we’ve been discussing things in detail:
Wishes Upcoming PSA DirectStream MKII - Audio Components / DACs - PS Audio

A few things:

We’re not adding new hardware features to the DS Mk II at this time - feel free to talk about new features, suggestions, etc. on the above thread.

Don’t ask things like “When will the DS Mk II ship?” on this thread, feel free to ask such things on the above thread (tho don’t ask a post or two below someone else asking the same thing :slight_smile: ) BTW, the answer is ASAP. We’re entirely gated by logistics complicated by supply chain shortages, etc. At this stage we’re once again waiting for boards but have been told all parts are in hand for the builds.

Just as an indication that the DS MK II isn’t just a few parts upgrades from the DS here are thumbnails of the digital (on the left) and the analog (on the right) schematics for the DS (on the top) and the DS Mk II (on the bottom)

I’ll try to put together an overview of the differences tomorrow.




Guess I’ll start :slight_smile:

Are there any cases here where less is more with the DS?

Thanks for being so open about this Ted! Looking forward to learning…

What was the list of key points on which the DS2 was designed to surpass the DS?
I’ll hope that dynamics is one of them.

I am proud of how simple the DS actually is. Using an FPGA greatly simplifies the digital input and digital processing. Having the analog output being passive (if you don’t count the opamps, aka. digital switches) leads to a simpler design, etc.

Features like galvanically isolating all inputs and outputs adds a layer of interfaces everywhere. Having two FPGAs isn’t really complicating things much, but it does require that much more wiring, bypassing, etc. on the boards. Having two reclockers instead of one obvious adds parts, but I’d claim it doesn’t add complexity.

The critical parts of the system for the audio path are still very similar, just with better parts and better power supplies. The new attenuator system is more complicated than switching in a resistor, but it is actually simply switching in one set or another set of resistors at a different place in the audio path.

All in all, I don’t think there much of an increase in logical complexity, tho the schematics are certainly fuller.


As I mentioned I’ll do an overview of the top level differences tomorrow (or Sunday.) There is a sense of ease with the Mk II and how it handles dynamics that’s missing from the DS. Part of the ease is from better power supplies, part of it is having more voltage headroom in the analog output circuitry, etc. I’ll talk about this in a later post.


I’m looking foward to your overview!

There are two views of the changes in the DS Mk II, goals and technological answers.

The first goal we’ll talk about is lowering noise from the digital inputs. Lowering noise was the majority of the work on each DS mountain top. A blacker background has many benefits: more low-level detail, which can bring out the ambiance of the recording making it more real, it can let you hear more nuance in performances (like seeing the singer’s mouth shapes, perhaps that’s only because I’m a singer :slight_smile: ) Lower noise helps the rest of your system to disappear and let the performance be center stage.

The DS did a reasonably good job dealing with jitter, it was very insensitive to incoming input jitter. But there were two places that it fell short of really showing that off: ground loops and FPGA induced noise.

We’ll talk about ground loop treatments today.

Since the digital inputs were not galvanically isolated ground loops could add noise of varying types depending on the source and how it was connected. The amount of noise ground loops pick up is proportional to the loop area and if the loop included units being plugged into different outlets, that loop could be huge. It was also likely that there would be a computer somewhere in the system which would also make a groundloop, but probably more often they contribute gobs of electrical noise.

The Mk II addresses much of this with (defeatable) galvanic isolation on all inputs and outputs. But not all galvanic isolation is created equal. Most of the single chip isolators either run slowly (e.g. optical based) or are intended for isolation of large voltages in industrial type applications. Those isolators’ main goal is to provide a safe logic connection across, say, a 3000V or 5000V barrier. These isolators expect to be used in noisy applications and so any additional noise they create isn’t a problem if it doesn’t interfere the logical signals it’s passing. There are capacitive and transformer-based barriers which require a high frequency signal being turned on and off to represent 0s and 1s. Adding a high frequency signal that’s correlated with the input signals is about the last thing a DAC or ADC needs.

If you look at the datasheets for some of these isolators they have to have a section on how to meet FCC regulations, i.e. how to mitigate the noise they produce. We can’t have that being a problem. There are some isolators that don’t use capacitance or inductance to isolate the signals and also don’t need to use a high frequency burst of energy to represent a transition or a 0 or 1, etc. The problem with them is that they cost a heck of a lot more than the cheap $1 or $2 capacitance based isolators. A quality four channel IC used to be approx $3 to $4 in quantities of, say 1000. Prices have more than doubled in the last couple of years, now they run $6 to $11 in 1000 quantities depending on additional features and packaging. Loosely speaking we need one per each I2S input, three for USB, and three to talk between the digital and the analog card. This is a cost I’d like to avoid, but good isolation is important.

Isolating TOSLink is free :slight_smile:

Isolating AES3 and S/PDIF is reasonably cheap, they are speced to be isolated and you can buy quality pulse transformers that do that task well.

Isolating I2S and USB takes a little more work. They need active components “outside” the isolation barrier. In the case of I2S it’s basically a simple LVDS receiver - a chip that receives the differential pairs from the HDMI cable and converts the signals to standard logic signals. We also support providing 100mA of 5V to the I2S device so we’ll need to do that too.

USB is a little more complicated - one approach is to isolate the four USB wires: Data+, Data-, VBUS and ground - but this isn’t easy, the VBUS line both provides power but it also signals things like a new connection, whether a device is a USB Hub or an endpoint device, etc. And it signals this in strange analog ways, not with a simple digital protocol. In the past the chips that supported this only supported USB 1, then the better ones supported USB 2, but not USB Audio, they couldn’t be relied upon to pass the data thru in a timely manner. There are now a few (not cheap) single chip solutions on the horizon, but we’re not waiting for them and the below solution is actually quieter and cleaner.

The interface between USB and the FPGA is I2S, so we can “simply” do what we do for I2S and put the USB transceiver chip and support on the “power island”. Then we only need to provide 5V along with the I2S across the isolation barrier.

If you look at isolated 5V to 5V supplies, they mostly have one thing in common: they are switch mode power supplies :slight_smile: What’s worse most of them rely on a transformer with high frequency signals which would generate noise across the isolation barrier. In the DS Mk II we use a high frequency edge controlled differential signal across two caps for the isolation and on the other side we have a small traditional linear power supply: a bridge rectifier and filtering. That can be a much quieter path. There are some gotchas, like using diodes for a bridge on a 5V power supply really lowers the voltage: say about 1.4 volts. So instead I use a MOSFET H-Bridge as a rectifier bridge: with MOSFETs you can have a lot lower voltage and they can switch cleaner than a diode.

Here’s the isolation for S/PDIF and the two AES3 inputs:

Here are the isolation islands for USB and the two I2S inputs:

The white chips with three legs are optically controlled switches to implement the ground lifts.

The board pictures I’ve shown above are the ones I’m using for development, but they have cheaper but noisier isolated 5V to 5V supplies. The current Mk II boards are designed with the supplies I described above and here is a picture of them on the TSS:

You can see the input caps and the high frequency edge controlled driver on the right side. Near the middle are the caps crossing the isolation barrier, then the MOSFET bridge some high frequency bypass caps and then the more traditional SP-Cap to provide power to the USB or I2S input circuitry.

When you look at the whole digital board:

Basically, the bottom 1/3 of the board is mostly galvanic isolation surrounding a few chips :slight_smile:



Thank you, Ted


This is fantastic, Ted. What a rare treat!
How long will finished units be run-in, “put through their paces”, before they’re released for sale?

1 Like

I’m running rev C, the boards that are begin built are rev G. Most of the revs were replacing parts that disappeared from the face of the earth :slight_smile:
Anyway, we need to verify that nothing got broken with the various changes and then well build a bunch. Beta will come after that, I have no idea how long that will take, but I have no reason to expect the Mk II to burn in any faster than the original.
So I can’t really answer your question :slight_smile:


Tanx Ted

Thank you Ted. Cool stuff. One thing for sure, I have never been on a forum or mfg. site where you get updates and/or feedback like this. Almost feels like I’m involved in the process with this level of data. Let’s hope for a successful rev “G” build and Beta. I’m all up for testing if approved.

Great stuff Maynard!


Great stuff Ted!

Is the TSS in a similar state as the Mk II, in a much earlier state with lot of things finally to design, or will it be just slightly revised/finalized due to insights during DS II‘s final developments?

1 Like

I’m updating the TSS with the relevant changes from the Mk II. The TSS boards I have work as designed so in one universe we could order boards for it soon. There’s always the chance that I make a mistake doing the updates, there’s also the chance that when we get the Mk II into beta we discover a mistake, on oversight or simply something we could do better. If any of these happen we need to update the TSS accordingly.

We have decided to make the TSS interfaces to the rest of the unit match the DS Mk II’s where possible. That means that much of the (non FPGA) software and some of the hardware can be shared between the Mk II and the TSS. This is a good thing, the user interface doesn’t really care that the analog is on the other end of an optical cable, it’s up to the FPGA code to talk to an optical cable instead of a local ribbon cable. It’s also a good thing because that part of the TSS’s boards will have already been debugged and proved so that part of the process should go more quickly with the TSS than the Mk II.


In this context the parallel development of both makes sense to share resources. Otherwise I sometimes doubted if it makes so much sense to release the first bigger DAC nearly in parallel to the new smaller one and not wait for further possible improvement options coming up to ensure a bigger distance between the two.

1 Like

Hi Ted,
Have you already chosen a name for the first “definitive” FPGA sw.
Or do you now have different sw versions and the choice is still to be made?

1 Like

Tho I’d be comfortable releasing the FPGA software as it stands, I expect that feedback from the Beta users will guide a change or two, tho perhaps not directly related to sound quality.

I don’t know what paradigm will be used to name software releases. The internal release numbers are still counting up from Sunlight :slight_smile:


I dig “Massive” (#2 on the list of CO 14’ers)

“Uncompahgre” has a nice ring to it, but may not be the best choice for various reasons.

On that Ute word track, “Tebeguache” also sounds cool - sounds like it coulda been a ZZ Top rekkid - and has a cool meaning:

"The Tabeguache Band took their name from Tava (Ute for “Sun” and also known as Pikes Peak). Tabeguache is a Ute word meaning “People of Sun Mountain .” Chief Ouray was a Tabeguache Ute, and was one of the most famous of all the Ute Chiefs.

Butcha know - there’s always "Lincoln":cowboy_hat_face:


As I obliquely implied above the noise and jitter generated in the FPGA was a major source of work in the DS’s FPGA software. The Xilinx FPGA tools keep track of jitter at every point in the FPGA, but the goal of the routing software is to keep that jitter from becoming large enough to disrupt the logic function. But short of that the software doesn’t try to minimize jitter. The FPGA hardware has separate routing networks for clock like signals to keep jitter, skew and other potential corruptions to a minimum. Most FPGAs provide something akin to PLLs to generate clocks based on other clocks. The output clocks may need to be phase aligned with the PLL input clock (or not.) The PLL can be configured to minimize the effects of input jitter, to minimize the output jitter or some compromise in the middle. (I’m getting side tracked.)

The FPGA software also has to worry about noise generation. One major source of noise is when signals make a transition: the more nodes a network drives the bigger the effects a transition has on the power supply: not only potentially lowering the voltage in a local are of the FPGA, but also potentially raising the ground level in a local area. The clocks are usually the biggest networks and generate a lot of noise on each transition. The Spartan 6 that the DS used had DCMs (Digital Clock Manager) which were like PLLs. One of the features of those modules was that for any input clock they would provide four outputs of that clock at 0, 90, 180 and 270 degree offsets. It turns out that each of these has differing jitter and noise so one trick I used in the DS’s FPGA code was to use phase 3 (270 degrees) for critical work since that had the smallest amount of jitter. Each trick like this made an audible difference in a software release.

The DS tried to keep noise on the FPGA down by using more bypassing than the minimum recommendations, by careful routing of clock signals and other FPGA inputs and outputs and by reclocking on the analog board to try and keep the rest of the analog board from reacting to noise from the digital board.

A few of the problems with the DS related to the above were:

  1. When I was routing the FPGA on the DS I accidentally didn’t separate the power and ground of the power supply for the PLLs from the power supplies for the FPGA inputs and outputs. I was annoyed with myself because I’d carefully separated them on my original prototype and on the DS Jr. So this meant that transitions on the FPGAs input and outputs would cause more jitter and noise for the internal FPGA clocks than they needed to. If we ever had to turn the boards on the DS that would have been one additional thing I’d have fixed.
  2. Noise from the switching inside FPGA also polluted the system’s overall 3.3V and 5V power on the digital card. I used a lot of bypassing but, bypassing can’t clean up everything. In an ideal world that noise on the 5V supplies wouldn’t have affected the analog board’s 12V supply, but there are always effects. The DS modders know what a difference using a completely separate power supply for the analog board makes.

So what’s different in the Mk II related to these things?

The newer FPGA used in the Mk II keeps noise down internally a lot more than the older FPGAs in the DS. They have a different architecture for clocking and new different PLL implementations. You can get more done in each cell of the new FPGA so there are fewer connections between cells so (assuming the same complexity of FPGA code) there’s less noise generated by signals connecting cells together.

The Mk II has two reclockers in series, this should filter out more noise from upstream.

The Mk II has power supplies for the digital and analog cards that are more separated from each other and they also regulate their voltages better. This helps to isolation interactions between the cards thru the power supplies.

The FPGA PLLs in the Mk II have their own power islands :slight_smile:

In the Mk II FPGA I’m using an entirely separate clocking network just for clocking the DSD outputs. Its phase is adjusted to transition when no other clocks in the FPGA are transitioning. The big change in the Sunlight release of the DS from previous DS software releases was taking a step in this direction so we know that it matters.

The Mk II has more bypassing around the FPGA and higher capacity regulators for the three different voltages that the FPGAs need.

The isolation between the FPGA and the analog card’s reclocker on the DS was done by capacitors. On the Mk II we are using explicit digital isolation chips with the FPGA facing side powered from the digital card and the reclocker facing side powered from the analog card. There are three isolators, one for the clock from the analog card to the FPGA, one for the differential DSD signals from the FPGA and one for the control signals from the control processor on the digital card to control things like the configuration relays and the VCXO rate.

The ribbon cable from the FPGA to the analog card is a more expensive better-quality cable than the one in the DS. It should introduce less jitter and shield the DSD signals from more noise than the one in the DS. It also doesn’t physically go over components on the analog card.

You can get an idea of the cable’s size by comparing it to the screw in the bottom left of the image.

All in all the biggest sources of noise from the FPGA have been eliminated or at least remediated.