Ted, I can make those changes on the i2s database. I’m assuming these are the correct PCM / DSD multiplexed pin assignments?
PCM Bit Clock / DSD Bit Clock
PCM Word Clock / DSD Data Left
PCM Data / DSD Data Right
Jesus R
@vortecjr
Jesus, the mere mention of your name and you pop up.
If only your “father” was so responsive. ~X(
If you happen to run into him up ther please put in a word or two for “World Peace”. 
I always put the “R” after my name so you guys know not to expect to much:)
Jesus R
Ted, I can make those changes on the i2s database. I'm assuming these are the correct PCM / DSD multiplexed pin assignments?
PCM Bit Clock / DSD Bit Clock
PCM Word Clock / DSD Data Left
PCM Data / DSD Data Right
Sure, but actually we use
PCM Bit Clock / DSD Bit Clock
PCM Data / DSD Data Left
PCM Word Clock / DSD Data Right
My prototype had a circuit board that was twice as thick and that extra mechanical stability seems like a good idea. Tho I looked at ceramic boards (and also things like Teflon boards), they seem like over kill with no particular return. I don’t have any very high speed signals and the very fast edges I have in a few places are differential and well terminated. Using 2 oz. copper everywhere and ENIG seem more useful.
I’ve looked at LiFePO4 batteries. They seem to have the instantaneous current delivering capacity to be interesting in power supplies. I ran one of my prototypes off of them for months. I had two 12V banks and charged one while using the other. I got about 3 hours of listening per charge. Still they don’t seem to have a significant audio advantage over a well regulated AC power supply. The DS is pretty close to a constant current load and doesn’t need more or less power as the audio changes. So the big thing is using enough high frequency filtering to isolate the guts from crap on the AC lines and to keep the DAC from injecting crap onto the AC lines.
A separate chassis for power supply and the DAC seem like enough more “mass / guts ratio” 
Using a more rigid circuit board and staying away from microphonic components seems to be a bigger return than even more mass.
The FPGA doesn’t generate much in the way of heat. Tho my big prototype ran very hot, all of that heat was in the power supplies. I definitely would use a FPGA with more computing capacity and speed, if for nothing else that room for new features or more advanced filters, etc. The factors involved in the choice between putting the digital card in a separate box or the power supply in a different box seems to go towards separate power supplies. You can control the EMI and signal line noise from the FPGA fairly easily, we just aren’t running that fast…
There aren’t much better crystals available. I did get custom VCXOs from Vectron for my prototypes (at about $200 a piece) but the current VCXO has excellently low phase noise.
If we can put the digital and analog circuitry on one board then the only internal wiring required would be from the power inlet to the power supplies (and if we use a separate box for power supplies, the box to box connections. Controlled impedance differential pairs on a circuit board beat almost any kind of explicit wires…
The digital and analog sections are galvanically isolated (except for system ground.) They are terminated differential connections which are capacitivally coupled. The only control wires from the digital to analog card are the VCXO frequency selection and they are slow speed connections thru high impedance connections. They don’t cause any problems.
More fun reading from Ted! This suggests that Ted could build a better and much more expensive DAC but that we are already well into the curve of diminishing returns.
J.P.
You’all got the benefit of my cost-no-object prototype. The real work since then has been getting the cost to a practical point while loosing the minimum audio quality. Some of the big DAC was redundant implementations so I could A/B, but mostly the experience it provided was invaluable in informing possible cost savings.
It is good to see that all ‘objections and comments’ are met with reasonable explanations making it a no compromise project. Your baby seems well thought off, Ted!
Frode
frode said: t is good to see that all 'objections and comments' are met with reasonable explanations making it a no compromise project. Your baby seems well thought off,
This is something I always value - when people know what they are doing and why.
Ted, I can make those changes on the i2s database. I'm assuming these are the correct PCM / DSD multiplexed pin assignments?
PCM Bit Clock / DSD Bit Clock
PCM Word Clock / DSD Data Left
PCM Data / DSD Data Right
Jesus R
Howdy Jesus
We switched the left and right to match this in the FPGA code that went out to all but Gordon (and perhaps another one or two, the guys at PS Audio are watching that.)
-Ted
10-4 and thanks for the update…
Jesus R
tedsmith said: We switched the left and right to match this in the FPGA code that went out to all but Gordon
Gordon is ambidextrous, he does not care :D
So this means that current FPGA code prevail or will the original pin out assignments in the I2s database take precedence for the next revision of the FPGA code?
We are talking about only the left and right channels of raw DSD over the “I2S/HDMI” connector, which then is neither I2S nor HDMI 
Since the DS isn't released yet, we decided to go along with Jesus's recommendation to be as compatible as possible for the new raw DSD input feature.
The one down side is that now the NuWave Phono Converter software needs to be updated as well, but probably next to no-one will have an NPC hooked up with raw DSD over the "I2S/HDMI" cable so this shouldn't be too much of a hardship.
The current I2S assignments will remain the same as the PWD.Ted,
Would I be correct that NuWave Phono Converter can be used with analog outputs of SA-CD player to do A-D conversion? If so, have you evaluated this into the DS from the NPC ?
Thanks,
Will
You are correct that the NPC can snarf analog, e.g. a SACD player, and either record it over USB to a PC or send it along in digital form. One of the digital connections provided (“I2S”) is capable of DSD and the DirectStream can consume that DSD.
I’ve personally only used my test NPC for testing compatibility with the DS. I use a low res XMOS USB card for my analog source since I can drive it with test tones easily from the PC.
I believe Paul has used the NPC -> DS for playing vinyl, I don’t think he has a SACD player on hand.
If I had to guess, the NPC would probably do a pretty good job of digitizing SACDs: you could probably beat the redbook layer of most SACDs.
The high rate is only in a small area of the FPGA and it’s digital there so there won’t be any interference from external RFI that affects it any differently than any other signal in the FPGA. If the question is if that signal will emit significant RFI from the FPGA to the outside of the DAC, it’s a pretty small area for an antenna and the DAC is fairly well shielded. In fact we’ve been able to delete some caps that were put there to ameliorate EMI since they turned out to not be needed.
Why does this strike you as odd? Designers have been upsampling PCM for many years for filtering, etc. Why not do the same with DSD?
Well, the upsampling of DSD is not really required is it?
It is required for single rate DSD (other wise the passive output filter isn't steep enough.)
Double rate DSD is more subtle. If I knew absolutely that the double rate DSD used the same (or lower) modulation depth, didn't exceed the amplitude limits, etc. then I'd know that I could bypass the upsampling and remodulation. Otherwise there might be a little distortion and at worst absolute crap might come out. By digitally lowpass filtering the incoming double rate DSD I can force it to be "legal" and then can use my sigma delta modulator and matched passive output filter to render it cleanly no matter how it was constructed.