Ted Smith

I will say that I have no intention of doing DSD512 in the DS. DSD256 may happen if I get inspired. It will depend on if I see a clear way to not impact the current sound quality. Tho the hardware passive output filter is designed for DSD128, that's not really a problem. The VCXO clock is 8FS so there's plenty of room there. Not doing twice the work in the IIR upsampling filter is the real trick. So either I do some kind of FIR instead of the IIR or I liberate some serious math resources elsewhere - both of which could easily negatively affect sound quality.

I see it too, mostly the first time I play something in a new listening session, but rarely at other times too. It usually "heals" itself if I stop and start or skip to the next track. Both with foobar2000 and with JRiver MC 19 and 20. If it matters I'm going to a PS Audio DirectStream DAC.

Before the DirectStream the "HDMI/I2S" connectors were used exclusively for I2S on PS Audio products and hence most PS Audio customers think of it as the "I2S" connector. In addition to accepting PCM (and hence DoP) via I2S, the DS also supports raw DSD (Clock, Left Data and Right Data) over the same connection - there's no ambiguity between them. After raw (or native) DSD is received over the I2S (HDMI) connector the DS does convert it to DoP just to take advantage of the already existent DoP path/processing. FWIW Tho in the end the master clock (tho not fixed) is indeed a bigger contributor to output jitter than is input jitter, the key point re input jitter rejection is that there are no PLLs, FLLs, clock recovery etc. that are used to interpret any digital input data - input digital data is recognized via pattern recognition not via processing at clock edges (whether explicit or recovered.)

Yep, to use the PCM FIFO in the FPGA the DSD needs to be packed into 24 (or 16) bit words anyway so the theoretically "purer" path is polluted... To be "clean" and have a separate DSD FIFO adds a lot of muxing/ demuxing and more memory usage...

Howdy In a player it's not obvious which method will have better sound quality: wrapping DSD in DoP or using a higher sample rate. It's easy to imagine either one causing sound quality degradation depending on the rest of the system. My hypothesis is that certain DAC chips get a cleaner (lower jitter) clock from the 2.8MHz input of raw DSD compared to the 176.4kHz clock of DoP. There is marketing pressure to support raw DSD because some don't understand that DoP is lossless and cheap and/or some believe that raw DSD is more "pure" than DoP. When it's convenient we will support raw DSD over USB just for the marketing checklist, not for any particular technical reason. In the FPGA implementing something to get raw DSD thru the same FIFO as PCM or having separate PCM and DSD FIFOs is a more code/processing than the minuscule work of wrapping raw DSD into DoP and using the extant DoP/PCM path. In general any extra code is a chance for bugs, takes more work to test and often decreases sound quality. -Ted

I don't think so. Everyone needs to test these things in their own systems. I have other paths from my PC to the DirectStream besides USB, but USB can do double rate DSD and uses fewer cables/extra boxes when I go on the road. In the DirectStream there's nothing magic or more direct about I2S inputs than other inputs, in fact the TOSLink input is the simplest - a wire from the TOSLink connector to the FPGA. Internally the I2S inputs form the HDMI connectors, USB and the bridge all talk to the FPGA with I2S. Since the DirectStream doesn't recover clocks from any inputs jitter differences between the inputs don't matter. The real differences are things like groundloops, EMI, etc. the I2S cable often has better grounding that other cables so it has an advantage over other cables. TOSLink has the advantage of galvanic isolation. USB has the problematic VBUS connector which is another way to receive noise and pass it to the DAC and hence is at a bit of disadvantage. Using Ethernet can also introduce groundloops and a lot of noise, so comparing the bridge to other inputs is even more system specific. -Ted

Howdy Ted You asked "I welcome Ted Smith to please tell us why this last chapter (or more appropriately the first several bad ones) of listening happened, and why I am getting such different sonic experiences with different inputs." It was surprising to me that no mention was made about which versions of the DirectStream firmware were used for various listening sessions. I suspect that the final listening with the Signature Rendu was done with release 1.2.1 of the DS firmware and the earlier, less fulfilling sessions were done with earlier versions of the firmware. If so, ... The more controlled experiment of testing multiple inputs with the same source hooked up simultaneously (so that the goundloops and other system specific RFI, EMI problems remain constant when switching inputs) will reveal that the sound quality of the I2S, AES/EBU, S/PDIF and TOSLink inputs are much closer on the DirectStream than they are on most DACs. The USB and Bridge inputs almost certainly have different electrical interferences with the rest of the system than I2S, AES/EBU, S/PDIF and TOSLink. At most one can hope that a component doesn't add significantly to the electrical interferences in a system. No component can undo the effects of external interference(s) on other components in a system. -(another) Ted

Talking about bit widths like there is only one (or a few possible) bit width(s) is wrong (or at least very simplistic.) Any time you do math you change bit widths (e.g. adding any two numbers requires one more bit for the output than for the inputs, doing a multiply takes as many output bits as the sum of the input bit widths.) Many DACs say that they are 32 bit DACs, what they really mean is that they round (or truncate) to 32 bits after each filter or chunk of math. In an FPGA I'm not restricted to multiples of 8, 16 (or whatever) bits and I use what ever number of bits that numerical analysis says is required to maintain the desired accuracy. In general I keep one more bit on the top and four more bits on the bottom than I need between filters, etc. The final upsampling filter does indeed produce 30 bit samples @ 28.224MHz. The final remodulator uses varying numbers of bits all over the place, but at the volume control it uses 30 bit wide samples + a 24 bit volume into a full 54 bit result (with an extra bit to keep the FPGA happy at this point.) All of those bits are significant in all downstream operations up to the ultimate quantization to a single bit output. This remodulator is an essential part of any work on DSD and (like in the Sonoma) is a place to do "free" amplitude scaling as a part of the remodulation process.

By listening. I think you'll find that the reviewers who listen agree. Tho there is more distortion with extremely loud bass than I'd like, I don't see the same levels as they measure. Still, as you mention, if your loudspeaker and room have more distortion than that and what you care is the sound it's not clear that the DAC is the weak link.

Nope, I'd rather have less distortion overall, and if I could get it without throwing the baby out with the bath water I'd take it. Every point in the design I chose the most technically correct way of doing things and I didn't feel the need to do any voicing. By using our ears we did discover things that we could do better, but in the end I vetoed doing anything that didn't make sense technically. The "voicing" that PS Audio refers to is actually just using the ear to pick the layout of the resources in the FPGA. Since moving things around in the FPGA has no technical disadvantage I didn't really care which version they liked the best if it still sounded good to me. My comments about measurement were more directed to the measurements of the noise floor. Single bit DACs are inherently linear and hence very accurate. Conversely PCM is very precise (lots of bits) but not all multibit DACs are extremely accurate. We strived to get the most accuracy possible and weren't as concerned about precision. At a different price point we'd further improve the power supplies, etc. to lower the noise floor further, but since the DS sounds incredibly black, has an accurate soundstage and has correct tonality, we don't feel bad about the noise floor even if it isn't ideal.

There's a balance between having an open sounding top end and too much ultrasonic noise. Still if people expect a significant FR difference between, say, 192k sample rate files and 96k sample rate files they are implicitly asking for FR above 48k. The DirectStream's output filter has a gentle roll off starting at about 50k. The noise from the digital noise shaping in the DS starts rising above the noise floor at about 60k so the ultrasonic noise never gets too loud before the output filter brings it back down. Or, put another way, the DS has less ultrasonic noise than a typical SACD player. Still, some have claimed that part of the DSD sound is the "dither" that it's ultrasonic noise adds... Personally I think they might have been struggling to explain how it sounds good in spite of some of the things they were measuring looking bad. I feel the explanation is simpler, the things they were measuring might explain at least a part of the sound quality of a PCM dac, but are less well correlated with the sound quality in a DSD based DAC.

I didn't mean to imply that editing on some workstations convert everything to DXD, if it's just simple edits only the crossfade is converted to DXD and back to single bit DSD and the material around the edit is left unaltered. I'm sorry that my careless wording above probably implied something worse.

I'm pretty sure nothing I say will end the discussion about PCM vs DSD. It's often more of a religious debate or a confusion of terms than a practical discussion. In the limit DSD is high rate noise shaped PCM - does adding zeros to DSD samples in and of itself some how un-noise shape or change the rate? Does multiplying by a gain un-noise shape or change the rate? Well only if you drop significant bits from the result of the math. The DirectStream does the same math to PCM and DSD then applies a volume and requantizes it to double rate single bit DSD. Requantization in DSD land is analogous to dither in PCM land. They both allow less loss of accuracy than would naively be expected when narrowing the sample width. In a little more detail I'll quote from a related FAQ that I wrote for the PS Audio web site: .... states that conversion between format dsd and pcm is an unwanted thing. Can you explain how your DAC benefits from the conversion rather than not? Answer: Well converting DSD to low rate PCM is bad. In fact, in spite of that, many SACDs are actually mastered with a workstation that converts DSD to 32 bit samples at 384kHz (DXD) and I would contend that that sample rate is too low. But allowing single bit DSD to widen when you do math on it isn’t a problem at all. There MAY be a problem when you requantize (use a sigma delta modulator) to get back to one bit. Being clear: there is no loss of information when doing sample widening in PCM or DSD. There CAN be loss of information when you do math (or dither) carelessly in DSD as well as in PCM. In the DirectStream we need to convert single rate DSD to double rate DSD so the DirectStream only needs one passive output filter designed for one frequency. The analog filter required for single rate conversion either is steeper than one would like or would have a cut off that’s lower in frequency than one would like. Double rate DSD gives the freedom to have a less aggressive output filter that starts rolling off at a higher frequency. It also allows less aggressive noise shaping in the sigma delta modulation process which lowers the ultrasonic noise introduced during noise shaping. This allows the well known “DSD noise hump” to be lowered by 40 or more dB and also allows it to start nearer to, say, 60kHz instead of 20kHz. If one were to repeatedly requantize single rate DSD the extra noise that would be introduced could eventually rise above, say -120dB FS at 20kHz and would certainly add more noise that that at 30kHz or 40kHz. A few requantizations (say from passes back thru an analog mixing board in SACD mastering) aren’t a practical or audible problem, but too many would be. On the other hand things are materially different for double rate DSD. The only thing that changes in with multiple requantizations at double rate is the particular details of the noise that’s generated by noise shaping. That changed noise is at a very low level over the audio band (quieter than, say, -144dB FS). It also or only grows over -120dB FS well above the audio band, say at 60kHz. (That higher frequency noise is also filtered by the analog output filter.) The number of requantizations required to have audible noise growth is quite large. Over the audio band this noise is less than the noise used in PCM processing to dither back to 24 bits from wider intermediate PCM results. Some practitioners even recommend not dithering back to 24 bits when processing PCM which actually adds even more noise if any non-trivial math is done. Perhaps in an ideal world we might handle the special case of double rate DSD input specially, but no-one would ever be able to tell that we did. -Ted

Interesting statement - PCM was an afterthought on my prototype.

Cost? The connectors/transmitter/receivers are fairly costly (compared to all of the other consumer connectors, transmitters and receivers.) Some audio equipment uses AT&T ST glass connectors/fiber, I had them on my prototype but there's not really a standard.