The next DirectStream update?

“” It is the gift that keeps on giving! Ted keeps giving us a better sounding DAC with each update! It is so great to be able to get substantial improvements without having to spend big $. “”

Absolutely !! I remember the first time I heard the DS; it was one of those special WOW moments. My then Linn DAC cost more than twice the price of the DS and when I compared the DS against the Linn DAC - DS killed it.

It definitely is “unique” in the world of audio, to have this product that improves year on year but doesn’t cost the owner anything.

With any other manufacturer Redcloud would have been a brand-new DAC, the latest statement product in their range costing tens of thousands.

The DS along with a few other products (which cost ‘significantly more’) that I own are in a unique stratum. And, when we get to value for money the DS wins hands down. I wouldn’t be without it !

1 Like

I agree 100%.
Long live Ted and the DS Dac !

Philippe

2 Likes

Thanks for the clarifications, that helps.

That’s sort of what I thought, I was answering for the DS so I didn’t address hardware changes. There’s a new feature in the TSS hardware that might help, but I’m not sure it’s going to work yet, if it does I’ll share more about it later. Hopefully the TSS hardware will be quieter because of it’s attention to isolation of digital from analog, etc., multiple reclocking, better local power supplies, etc.

In the DS software I’ve always tried to have all processing accurate to within a 144dB S/N even tho hardware is closer to 120dB (the final sigma delta modulation is a clear exception, I do it as accurately as I can but the noise shaping along with the final output filter preclude 144dB S/N in the near ultrasonic range.) In Huron and then again in Redcloud I’ve been spending more resources doing a more accurate SDM. In the next DS release I hope to do more better. (The new upsampler is using two new proprietary features to get more accuracy in the same number of bits in the coefficients.)

Yep that’s the hope, if the new upsampler works well it will be the backbone of the next DS release and it will also enable pushing the limits even more in the TSS.

Duh, I missed the DSD → DSD possibility in your original questions. Starting in Huron the oversampling to 20 x and back to 4x is transparent for DSD, but the sigma delta modulator will change things and in principle any extra processing of any kind is suspect for sound quality.

Bypassing the SDM for DSD would disable the volume control, and for some DSD sources (not SACD DSD sources) some noise might be introduced if the bit stream stays high or low too long - that would probably sound like mild compression for loud signals. Extra FPGA options (whether they are used or not) often hurt sound quality. For these reasons I’m staying away from adding a SDM bypass.

3 Likes

In essence a (filter based) upsampler merely puts N-1 zeros between samples (or repeats a sampler N times) and does low pass filtering to nuke extra images. (E.g. see https://en.wikipedia.org/wiki/Upsampling)
In brief zero stuffing (or repeating samples) leaves the original signal in the original band alone (except for scaling when zero stuffing) but it also adds (possibly frequency mirrored) copies of the information thruout the new frequencies in the wider bandwidth. Filtering the new signal back to the original bandwidth gets you back your original signal (except for scaling when zero stuffing.)
I.e. the FIR filter is 99% of the kind of upsampler I use.

The neat thing about FIR filtering is that it can exactly reproduce the inputs in one set of the output samples (e.g. at sample offsets 0, 8, 16, 24… if you are upsampling by 8) and FWIF each of the other 7 sets o samples at other offsets (1,9…, 2,10…, … 7,15…) has the equivalent information and can be used to get back exactly the original input samples by upsampling just those samples. If you implement FIR filters with fixed point math you don’t need to do any rounding or have any other precision losses except possibly when you choose which bits to use for the final output. I.e. a FIR filter is a convolution and you can keep all bits of each multiply and also all bits of the sum of those products. The “trick” is to use enough accuracy in the coefficients that you get the precision you want in the outputs - you can test that precisely by doing a (very slow) frequency sweep thru the filter and verifying that the pass band and stop band have the accuracy you want.

The math is simple (just an inner product for each output sample of the N coefficients and the last N samples.) The complexity comes in if you want to take advantage of symmetric filter coefficients, if you need to use more than one multiplier per output sample to get the job done in time, if you want to avoid all of the multiples by zero if you are using zero stuffing… These all amount to scheduling the order of the input samples and the order of the coefficients to be just in time for each of the multiplies you are using. The numerical analysis is simple, the optimized control logic can be mind bending.

1 Like

I’ve used code from Xilinx when appropriate (e.g. their various “macros” to make use of the clocking parts of the FPGA and their asynchronous FIFO’s.) I don’t use open source code or code from other vendors. USB is handled by the XMOS part and the FPGA just sees I2S from USB and the bridge (it doesn’t know the difference between the four I2S inputs or the difference between AES3, S/PDIF or TOSLink.) I wrote the I2S input routines, the bottom level of the AES routines (the part that does the pattern matching to decode to bits.) I used code from Xilinx to deal with AES3 framing, channel status, etc. and I used to use their FIR filters. But beyond that it’s all my code.

2 Likes

Whenever I read about those hundreds of aspects which still can and have to be optimized (as you do i.e. with the firmware updates and the TSS developments) until the “perfect” performance of digital audio is reached, as well when I think of all the quirks and limitations of analog…then I always wonder that even professionals claim since years, that there’s no way to distinguish a master from a playback with this or that technology.

Doesn’t this and the ongoing improvements of this technology we realize either mean:

…that they lie (don’t think so)
…that their system doesn’t reveal the differences
…that the master made with today’s technology are already too much compromised to serve as proper test objects
…or that the proof of an accurate recording/playback process means nothing?

I’m clueless by this non-logic

But I had a great listening day today again with today’s DS :wink:

Hello, just got a DD Sr with Bridge 2 hoping that I can do away with using an ultrarendu. I’ve now learned through through various threads that the pops I’m hearing is a known issue. I’m running Redcloud and the latest Bridge firmware and have tried lowering the output volume with no success. I’ve gone down to 80 and still getting these annoying clicks.

I’ve now reinserted my Ur and after listening to dsd’s for the last hour haven’t heard any pops. Even clicks at the start of tracks is many times lower in volume. I hope, like others, this will get resolved with future firmware release.

BTW, I love your videos Paul, and look forward to watching them before bed.

Terrance

I would not get rid of the ultraRendu. I did and I am now buying another ultraRendu to replace the one I sold. The ultraRendu sounds better than the Bridge II card. I tried to make it work, as it simplified the digital chain, and I wanted to evaluate fully unfolded MCA.

Now that MCA has proven to be uninspiring, I have no reason to accept the lower sound quality the Bridge II provides. Note that the DS with the ultraRendu sounds even better if you pull the Bridge II card from the DAC.

Thanks for the comments Speed racer. What PSU were you using with the Ur?

I am using a Teddy Pardo power supply and I am VERY happy with it.

Thanks, Terrance. As Ted has suggested on many occasions some of what you may be hearing can be caused by your source. He’s working on making them mute before they happen, if memory serves me correctly. Have fun and thanks for reaching out.

Did you every get a chance, or communicate with anyone regarding the Mano vs UltraRendu? I know you had mentioned the Mano in prior posts. Just curious…

No, I did not. I have been unable to find anyone I trust that has tried the Mano so I decided not to gamble and went back to a choice, the ultraRendu, that I know and trust. Ted has said that I2S isn’t really any better than USB on the DS if you have a good USB source. The ultraRendu is a great USB source and it sounds better than the Bridge II card. Easy choice…

This is slightly off topic, but could an ultrarendu be used to stream into an Oppo 205?

Makes perfect sense. I just picked up an UltraRendu and Uptone LPS-1 to run in lieu of the Bridge II for comparison.

Generally speaking, I default to purpose-built gear over off-the-shelf then modded gear, which is what the Mano is. It is essentially a Raspberry Pi that has been tweaked to no end. Nothing wrong with that necessarily, but the RPi was not originally built with the intent to delivery pristine audio. The UltraRendu was, and it has also stood the test of time, aka tried and true.

How do you think an UltraRendu and Uptone LPS-1 would sound into a DirectStream senior vs using a DMP? Most of my music is files I have downloaded and burned to DVD. Some hi-res, some redbook quality.

Thanks.

The ultrarendu/microrendu has an USB B output. Oppo 205 has a USB B input per a photo. If in doubt double check with Oppo and Sonore, but it looks like it should.image

1 Like

It’s easy to get an idea of the changes in the digital noise, but that’s not really meaningful, I keep it way below the 24 bits of the input data (e.g. below -180dB (30 bits) in the filters.) The noise I expect to lower probably won’t be measurable with sane equipment, it will be jitter and noise induced into power supplies from the FPGA and then not filtered out by bypass caps and other power supply filtering.

In the DS some of this bleads thru everything and affects the output minutely, I’m don’t see how in the TS by the separate boxes optically connected won’t nuke that noise and I believe that the reclocking in the analog box will kill the jitter (of course this is true of any FPGA code so it doesn’t answer your question.)

The rewriting of the filters should affect the sound staging similarly to going from 1.2.1 to Pike’s Peak or like going from Pike’s Peak to Yale. But not as drastically as going from Torreys to Huron.

I’m not expecting a measurable difference (tho there may well be one) but this should be like what John Atkinson said in his Feb 17 Stereophile DS follow up:

Before I did any listening, I performed a full set of measurements with my recalibrated Audio Precision SYS2722, but to my surprise, I didn’t find any differences. […] But when I listened to the PS Audio with the Torreys firmware […] I had to agree with Bob Deutsch. Even without greater measured resolution, it did indeed sound as if there was more resolution. I switched back between Torreys and Yale and back to Torreys and the impression of greater resolution with Torreys persisted. A paradox.

4 Likes

In 1, I’d probably say (if indeed it makes a difference:) “Fixed a bug causing a tick/pop in PCM <-> DSD transitions.” And (once again if it makes a difference): “Lowered more source generated ticks/pops in clock rate, PCM/DSD, deemphasis… transitions.”

In addition to items 1-4 I hope to also have user selectable polarities for each I2S input (the FPGA code is trivial (an XOR), so when it happens is really a UI issue.)

Those are the current plans, but I have another idea or two I’d like to flesh out enough to try. Who knows how they will turn out.

Point 5 - I don’t expect to have any specific work item for optimization of the LPF, tho the upsampling rework should firm the bass a little (I don’t know audible it will be.)

3 Likes

Ted, can the noise floor be lowered any more from where it is already?