New Holo Audio Spring2 DSD1024 DAC

[Miska]

On 12/8/2018 at 1:03 AM, matthias said:

Maybe the perfect DAC for @Miska?

 

Yeah! I certainly need to get one!

 

[Miska]

20 minutes ago, opus101 said:

I recall Jussi showing some result for a Metrum DAC a while back but that's just one datapoint and not particularly representative. Their old model which I looked into (think it was called 'Octave') used resistor string DACs which is rather unusual in the multibit audio world as most have gone with R2R - being more amenable to discrete implementation than Rstring.

 

None of the DACs you mentioned with the links are multibit type, as far I can see.

 

I have a Metrum Musette and that's where the results are from. Performs a lot better when running at 352.8/384k rate.

 

Holo Spring has two DACs in one box, R2R ladder - which performs notably better too at 352.8/384k. And DSD multi-element array that is similar to my DSC1 design, which performs best at 22.5792 MHz. I also have Holo Cyan DSD DAC, which is DSD-oly DAC and a bit like Spring, but without the R2R part (but Cyan has sweet spot more around 11.3 MHz).

 

Denafrips is another that is similar to Spring.

 

BB PCM1704 which is a ladder DAC can run at 705.6/768k rate with good performance. It really depends on a particular design how much the R2R rate can be increased before settling time ruins the performance. 16-bit part can be certainly run at higher rates than 24-bit part, because for LSBs to have effect, the DAC needs to settle to +-½LSB within fraction of the sample time for the precision to be useful. It is hard to say where the limit is without testing.

 

[Miska]

One way I use to improve linearity of those R2R's and work around setting time issues is to figure out the linear range at wanted sample rate and then set output word length to that one and employ noise shaping to increase dynamic range in audio band. This is why I added possibility to set output resolution in one bit steps in HQPlayer, for example to 17- or 19-bit.

[Miska]

3 hours ago, matthias said:

The Achilles heel of the first generation Spring was the USB interface. So quite a few owners used the Singxer DDC into I2S.

 

What is wrong with it? I haven't seen anything to complain about on mine...

 

[Miska]

3 hours ago, matthias said:

Some audiophiles on SBAF found that I2S is the best and USB the worst input of the Spring. 

https://www.superbestaudiofriends.org/index.php?threads/holo-audio-spring-dac-level-3-kitsune-tuned-edition-impressions-reviews.3172/

I think there is also some consensus about on CA forum.

AFAIK @Superdad uses the Singxer DDC into I2S for his Spring too.

 

I'm not seeing any objective data substantiating the claims...

 

53 minutes ago, Em2016 said:

https://www.computeraudiophile.com/forums/topic/38240-network-streamers-with-i2s-output/?do=findComment&comment=783773

 

Phase noise is certainly not a problem with Spring's internal clocks. And I have doubts that transmitting clock over a cable is going to improve anything, or at least I would like to see some hard evidence before I believe.

 

[Miska]

1 hour ago, Em2016 said:

Do I2S cables separate the digital clock from the digital data? Can that help with jitter?

 

Yes, but unfortunately they tend to send clocks to wrong direction, so instead of going from DAC to the interface, they send clock with the data which is a problem. It is difficult enough to get clock distributed properly on-board inside DAC, when you put it on a cable you have a lot of problems to expect, similar to S/PDIF and AES that also send clock. I2S was never intended to be used on a cable, it is designed for connecting chips together on a board.

 

In best cases the data is completely reclocked inside DAC after receiving it from I2S. I also have vague memory that Spring would be doing this too (in which case the external clock wouldn't be used).

 

[Miska]

2 hours ago, matthias said:

If I understand correctly there is no benefit of I2S in comparison to a good USB implementation?

 

No, it is not magic bullet because it is harder to get right than USB implementation. Especially because it depends both ends of the wire to get it right. And IMO, it practically requires reclocking at the DAC side, or implementation where DAC sends the clock upstream, opposite direction as the data. Clock is best placed as close to the D/A conversion stage as possible.

 

It also makes galvanic isolation harder, because if the I2S source has the master clock, it is at wrong side of the isolation barrier.

 

If there is a benefit from external I2S, it is likely due to other reasons than clock...

 

[Miska]

6 minutes ago, twluke said:

Hi Miska, thank you for this comment. However, I'm a little confused with it. Shown below is part of the description from the Holo Audio-KTE Spring 2 page:

 

  ...snip... (This feature i’m most excited for, as many of you know that I highly recommend i2s hdmi input as being ideal connection with our dac)

 

Currently I've been applying this I2S(HDMI) connection to My Cyan DSD DAC (via Hermes-BBB/Cronus from TPA) and have been quite satisified with this setting.

 

I cannot comment about that page, because I don't know background behind...

 

I'm running my Cyan DSD straight from my Xeon desktop using USB cable and at least phase noise is not an issue that way:

[Miska]

1 hour ago, twluke said:

The graph is quite okay. I think if he can not find the background to explain why the manufacturer recommends I2S HDMI input, then he should have stopped his comment as that point; no need to bring up the USB data graph.

 

I'm happy to also measure performance with external I2S source, if someone wants to loan me such. But I'm personally not ready to pay for such given performance of the built-in USB. Both Spring and Cyan perform better with built-in USB than USB interface of many other DACs ("fs clocks" or not).

 

What I'm trying to say is that based on my experience there's really not much to complain about USB interface of Spring or Cyan.

 

Why not USB graph? I would like to see similar graphs with I2S for comparison.

 

[Miska]

1 minute ago, matthias said:

@Miska

Comparing Spring1 and Cyan in NOS mode (DSD256 or DSD512) in a set-up with speakers (not headphones):

Is the Spring1 superior regarding SQ (not measurements)?

 

I've never compared it that way. Spring1 is on my loudspeaker system and Cyan DSD is on my office desk headphone stack... Now I want also Spring2 on my loudspeaker system (full width gear is just too big for my office desk).

[Miska]

20 minutes ago, matthias said:

@Miska

Did you compare (Spring1 only)?

 

Redbook > HQP to high rate PCM > PCM NOS mode

vs.

Redbook > HQP to high rate DSD > DSD NOS mode

 

Yes, I compared it shortly at the beginning. It works quite nicely both way, but I like more to run it at DSD512 so I have HQPE set to fixed 22.6 MHz output rate.

 

If you run it with PCM, set DAC Bits to 19 or 20, since the linearity reaches to about -120 dB level based for example on Holo Audio's data you can find in couple of places:

https://wildism-audio-hk.myshopify.com/blogs/news/holo-audio-xmos-xu208-spring-dsd-r2r-dac

You can also use noise shaping to improve SNR in audio band a little bit.

 

With the Spring2's higher PCM rate capabilities, one can probably utilize lower word lengths and noise shaping to improve the R2R performance even further.

 

You can also find some measurement data here if you scroll down:

https://item.taobao.com/item.htm?id=538890897934

 

I've also done my set of measurements I've discussed earlier somewhere on this forum...

 

[Miska]

9 hours ago, Superdad said:

Wow, 19 or 20?  I've had mine set to 22 or 23.  I'll try going lower.  Which dither setting do you think sound best with Spring 1 Lvl.3 and those lower DAC bits settings?  For PCM 384kHz (and I'm a fan of your poly-sine-short filter).

 

You could try NS5 or NS9...

 

9 hours ago, Superdad said:

Didn't you mean "longer" word lengths with the Spring2?  Not sure why the new DAC would want to go even shorter/"lower" than Spring1.

 

Because I doubt it will be able to settle to that accuracy at 1.5 MHz. But it doesn't matter because you get even more benefit from noise shaping, so the net result is probably better... If it manages 16-bit at 1.5 MHz it is already very good!

 

[Miska]

2 hours ago, matthias said:

In case of Spring1 or Spring2 do you think it is better to go for DSD upsampling when the settling time characteristics with R2R are unknown?

 

Probably it would be better to stick with DSD in any case, but it is just my opinion...

 

If the R2R side is good, then the difference between the two just gets smaller at 1.5 MHz PCM rate.

 

Here's a digital domain example of 16-bit output at 1.5 MHz using NS5 noise shaping:

 

Source is linear sweep from 44.1k file.

 

That is certainly much more than analog noise floor of anything. And it could be safe to assume it manages 16-bit at that rate.

 

[Miska]

12 minutes ago, 57gold said:

Jussi - Do you run a preamp with Spring1 to drive amp?

 

Understand that these DACs do not offer built in attenuation...though some models have a remote.  For filter or mode changes?

 

Yes, I have a separate preamp and power amp after Spring1. Spring1 is connected through balanced to preamp which in turns runs balanced to the power amp. My layout is such that equipment is connected with quite short cables (max 1 meter cable length) to the preamp in one double-rack located at side wall. And then preamp runs to the power amp located between the speakers, with about 3 meter cables. Speaker cables are about 1.5 meter long.

 

Preamp has stepped attenuator for volume control and also separate volume controlled output for subwoofer. Main channels are acoustically crossed over to subwoofer, so I have adjusted subwoofer low-pass frequency to match suitable point of main channel roll-off so that combined response is flat (done with measurements using REW).

 

[Miska]

4 hours ago, Em2016 said:

So the DSD conversion section/module of the Spring1 is different to the Cyan's DSD conversion section/module?

 

Is that why Spring1 is better at DSD512, compared with Cyan better at DSD512?

 

Or is Spring1 better than Cyan when both are at DSD512, more so because  different analogue output stages?

 

Especially Cyan is sort of black box, where DAC is just a swappable module sitting on the base board, I could even buy R2R module too and swap. But I don't know precisely why Spring1 is better at DSD512 than Cyan. It could be either the D/A stage or the analog stage after. I really didn't put much effort into figuring out which one is the limiting factor.

 

[Miska]

6 hours ago, Em2016 said:

I saw in the Cyan thread that early on there were issues with DSD256x48 base rate.

 

Was a firmware later able to fix this or is the problem still there because it's a hardware issue?

 

Cyan doesn't support 48-base DSD and Spring 1 doesn't either. So no difference in that respect...

[Miska]

Spring 1 puts sound out at 48k-base DSD rates, but uses 44.1k clock, so the content is played too slow. Cyan just goes mute.

 

[Miska]

10 hours ago, Em2016 said:

Does same apply to PCM x48k based rates. Not just DSD? @Miska

 

The Spring1’s 44.1k clock is used to output 48k based rates, even for PCM?

 

No, I think 48k PCM should work fine.

[Miska]

On 12/30/2018 at 3:15 PM, seeteeyou said:

Piero @hifi25nl already asked for DSD1024 support under Linux but Jürgen @lintweaker didn't seem to be interested

 

https://github.com/lintweaker/xmos-native-dsd/issues/28

 

I grabbed a copy of the driver of Spring 2 and found something relevant, I guess that quirks.c could be modified first

 

https://github.com/torvalds/linux/blob/master/sound/usb/quirks.c

case USB_ID(0x20b1, 0x3036): /* Holo Audio USB Digital Interface Gen1 */
case USB_ID(0x152a, 0x87c0): /* Holo Audio USB Digital Interface Gen2 */
case USB_ID(0x152a, 0x87c1): /* Holo Audio USB Digital Interface Gen3 */

Then something else like an additional patch might be created in order to get things going, most likely there will be even more necessary changes but I dunno

 

https://github.com/lintweaker/xmos-native-dsd/tree/master/SRPMS/patches/kernel

 

FYI - I found that driver here

 

https://pan.baidu.com/s/1hj5cTymhtF8Qr5zy1_YZCQ

https://item.taobao.com/item.htm?id=527818416876

 

This stuff is totally unnecessary with the new auto-detection code I made because 0x152a is Thesycon's VID and 0x20b1 is XMOS' VID and both are covered by the autodetection code, so the PIDs are unnecessary to be listed separately anymore.

 

The auto-detection code is already part of upstream kernels since 4.18.

[Miska]

On 12/30/2018 at 3:20 PM, hifi25nl said:

Audiolinux kernel is already patched with

 

   case USB_ID(0x20b1, 0x3036): /* Holo Springs Level 3 R2R DAC */
        if (fp->altsetting == 3)
            return SNDRV_PCM_FMTBIT_DSD_U32_BE;
        break;

I can add the other USB_ID

 

That too is pointless nowadays. There's no need to list every XMOS, Thesycon or Mytek PID. Only if there's a new VID that uses same style.

 

You should be able to safely remove all separately listed items falling under 0x152a or 0x20b1 VID because those are auto-detected. For my own kernels I've cleaned up that already. For upstream kernel I took more careful approach and delisted only the ones that I had at hand to test to be 100% sure.

 

[Miska]

19 hours ago, matthias said:

All the measurements they talk about on ASR are from Spring1.

Do you have a recent link about the superiority of the May DAC module in comparison to Spring2?

 

I wonder what Stereophile did with the Jtest measurement, because I don't get similar results from my Spring1...

 

Maybe they run it in NOS mode at 44.1k rate, which could explain... My measurement is 44.1k J-test24 file, upsampled by HQPlayer to 352.8k and Spring1 set to NOS mode.

 

[Miska]

6 hours ago, Hammer said:

Hi, thank you.  Does this mean NAA installed on debian running kernel 4.18 or later will support the Spring 2 DAC at DSD1024 natively?  That would be so amazing!

 

My custom Debian and Ubuntu kernels support it, as well as the latest HQPlayer OS image.

 

[Miska]

1 hour ago, Hammer said:

Hi, does that include your x64 NAA images?

 

Yes, I think I rebuilt the NAA image with relevant changes, version 3553.

[Miska]

2 hours ago, matthias said:

Maybe someone can shed some light on why the Spring is rather expensive in Europe in comparison to the US?

 

Maybe differences in tax system and how prices are presented due to such differences?

 

If you import it from US you'll end up paying customs and VAT on top... In US, there's a possible state tax added on top?

 

I have L2 versions of both Spring 1 and 2.

[Miska]

5 hours ago, ddetaey said:

On the Spring 1 the Output level with DSD is -6dB compared to PCM.

still the case with the Spring 2?

 

From my tests where I think I used -1 dB 1 kHz input... My figure for PCM, from balanced output is 3.8V RMS. And for DSD, from balanced output is 1.7V RMS. Noise floor level is a bit lower for DSD, but the difference is pretty small.

 

So yes, quite close to 6 dB difference.