HOLO Audio Spring DAC - R2R DSD512

[barrows]

10 hours ago, hifi25nl said:

I have been using the DIYINHK for some time now. Inside there are three high quality NDK clocks. The card does not need reclocking because there is not isolation chip inside, where Singxer needs it. Is isolation important? Some listening tests suggest the contrary, provided that the USB signal is clean. I like it simple. I don't like to isolate and after correct for the mistakes... but this is only my personal opinion. However there is a DIYIHNK version with isolation. The DIYIHNK card is also completely free from USB 5V signal. You can use it with a USB cable without power wire. Sometime I use an USB ethernet extender from Gefen, to be sure that USB signal is clean enough.

About LDVS some are suggesting that transmission with HDMI cable is almost jitter free, the problem is only before LDVS output chip and after input at the DAC. I am also curious to know what's happening in the Holo after I2S input.

The sound  with my adapter is very good. It can upsample up to 768K and DSD512 without dropouts. With Roon upsampling absolutely no bumps, only some rare little clicks. With Roon + HQplayer (embedded version beta 4.x), you need to put the volume down at boot and use a fixed sampling frequency in DSD, to avoid problems. However HQPlayer give a lot more choices!

I have the DIYINHK as well, while it works well, IMO it needs re-clocking for best performance as the output from the XMOS chip comes with somewhere around 200 pS of jitter, regardless of how good the NDK clocks are.  this is a well known situation with the XMOS chips.  Additionally, if the Holo uses the masterclcok feed at all, that also comes from the XMOS chip rather than directly from the NDKs onboard, so the Masterclcok is also jittered.  It is too bad DIYINHK did not allow for a direct feed from the NDK clocks to the output...

Of course, i am not sure how the Holo handles the I2S feed once onboard the DAC: does it use the I2S based masterclock, or does it re-clock to its own local clock?

[hifi25nl]

From DIYINHK, ref.: https://www.tapatalk.com/topic/10716-diyaudio/290015-new-usb-to-i2s-768khz-dsd512-1024-converter

"The hardware divider is a new secret weapon from XMOS new xcore200 XU216 chip. Although it do not have must information disclosed yet, but you can try to look in the code for the new xc function configure_clock_src_divide()

I use Lecroy oscilloscope with JTA option enabled and active probe to compare the input(from clock) and output(from xmos pin) jitter, it is about the same and unbelievable, miles ahead from it's competitor! or there is no competitor as of now"

 

What do you think?

[Bimmer100]

23 hours ago, barrows said:

I have the DIYINHK as well, while it works well, IMO it needs re-clocking for best performance as the output from the XMOS chip comes with somewhere around 200 pS of jitter, regardless of how good the NDK clocks are.  this is a well known situation with the XMOS chips.  Additionally, if the Holo uses the masterclcok feed at all, that also comes from the XMOS chip rather than directly from the NDKs onboard, so the Masterclcok is also jittered.  It is too bad DIYINHK did not allow for a direct feed from the NDK clocks to the output...

Of course, i am not sure how the Holo handles the I2S feed once onboard the DAC: does it use the I2S based masterclock, or does it re-clock to its own local clock?

 

This was an interesting question and asked Jeff to comment on this one. Here is his reply.

 

Jeff Zhu's quote:

"Correct. The signal generated by xmos can’t be used directly. It must be re-clocked. Also the galvanic isolation chip on the usb module also generates a lot of jitter. Another thing need to be noticed is the connector between the module and mother board. The contact impedance of that connector can be up to few hundred milliohm. When this impedance is inserted to the ground between mother board and daughter board. Any variable current through this impedance will cause a “ground bounce” and that ground bounce is essentially make the reference ground to be noisy. Then the noisy ground will generate a lot of jitter. That jitter can be ‘us’ grade. Far more than the ‘fs’ and ‘ps’ grade. So if you see any oscillators on the daughter board, no matter how expensive it is. It will be a rubbish clock though that connector down to the mother board.

 

You can see Spring put the main clock on mother board. And we use that main clock re-latch the signal from usb module. So, no matter what kind of jitter is generated by xmos chip, or galvanic isolation chip, or the ground bounce of the connector. It will be re-clocked and follow the performance of that oscillator. No waste.

 

A right implementation is the essence of design. I have saw a lot products are doing thing wrong but they use very expensive parts. Those are totally useless and simply waste of money. For example, when a 100 milliohm impedance going through a 5mA variable current. It will generate 500uV noise on ground. The ground is the reference point for all single ended signals. So that 500uV noise is directly modulated to the clock and became “huge” jitter.

 

The connector between the resistor ladder module and mother board is carefully selected. And we use multiple pins to reduce the impedance. And, the key part is we use some technique to make the current to be constant. Only a variable current can generated noise. If the current is constant. Then it simply became a constant value and not noise. So the digital algorithm of the resistor ladder module are specially design to make the current to be as constant as possible.  This is yet another “black magic” to be used on Spring."

[hifi25nl]

"You can see Spring put the main clock on mother board. And we use that main clock re-latch the signal from usb module" If I understand right, this is true not only for internal USB module, but also for I2S input? 

[tboooe]

I thought i2s input the clock comes from the source and the dac does not reclock?

[kaufenpreis]

The man surely knows DSD and I believe he uses Macs and PCs in his systems.

[Evo-No-Revo]

I am looking for some clarity on the SU-1 to Holo Spring.   I am going to drop down to less technical terms to get a baseline of understanding...

 

Is the issue that people are expecting the better clock in the SU-1 to override so to speak the lesser quality Holo Spring's internal clock for final output?  

 

Or has Jeff stated that the Holo's internal clock is actually the clock with the final processing.  So no matter what is done in the SU-1's clock the Springs's clock will assert it's electrical sound signature on the final output signal?

 

Then there is the question of whether the I2s and USB signal are handled differently with the Holo's clock. 

 

Is this basically the situation or should I start rereading this thread?  

 

 

 

[wouterk]

I asked Jeff the question on USB:

his reply:

"

         DXD is a 384K PCM stream, Spring can support it by USB and I2S port. Spring’s USB is quite good, but I suggest to add this https://item.taobao.com/item.htm?id=45642395436  It will help a lot on the usb connection of Spring."

The link is his Re clock USB device. For I2S the SU1 seems the most obvious solution because of the quality of the components used. 

[Altabay]

10 hours ago, Evo-No-Revo said:

I am looking for some clarity on the SU-1 to Holo Spring.   I am going to drop down to less technical terms to get a baseline of understanding...

 

Is the issue that people are expecting the better clock in the SU-1 to override so to speak the lesser quality Holo Spring's internal clock for final output?  

 

Or has Jeff stated that the Holo's internal clock is actually the clock with the final processing.  So no matter what is done in the SU-1's clock the Springs's clock will assert it's electrical sound signature on the final output signal?

 

Then there is the question of whether the I2s and USB signal are handled differently with the Holo's clock. 

 

Is this basically the situation or should I start rereading this thread?  

 

 

 

 

Thank you for asking this question.  I've been wondering myself after reading Jeff Zhu's comments relayed by Bimmer100 above.  On first reading I got the impression all input is reclocked, but upon re-reading I realized Jeff is talking about USB only: "The signal generated by xmos can't be used directly.  It must be re-clocked. (...) You can see Spring put the main clock on the mother board.  And we use that main clock re-latch the signal from usb module."

 

@Bimmer100, can you clarify?  Does the Holo Spring reclock the I2S signal?  Did Jeff Zhu ever state it clearly?

[Bimmer100]

1 hour ago, Altabay said:

 

Thank you for asking this question.  I've been wondering myself after reading Jeff Zhu's comments relayed by Bimmer100 above.  On first reading I got the impression all input is reclocked, but upon re-reading I realized Jeff is talking about USB only: "The signal generated by xmos can't be used directly.  It must be re-clocked. (...) You can see Spring put the main clock on the mother board.  And we use that main clock re-latch the signal from usb module."

 

@Bimmer100, can you clarify?  Does the Holo Spring reclock the I2S signal?  Did Jeff Zhu ever state it clearly?

The Holo Spring takes in the MCLK signal via HDMI i2s. it does not reclock this signal. so the 575 crystek's in the KTE-SU1/SU1 are being used in full effect.

BTW, I may have a few KTE-SU1's for sale, i spent the whole weekend building a bunch and preparing one for those who have been patiently waiting.

 

[Evo-No-Revo]

So the SU-1 clock is getting to have the final sound imprint via I2s so to speak.  Got it!  

 

Upgrading one internal clock in the Holo Spring would then have the potential of upgrading the sound of all the other inputs?

 

USB  - RCA coaxial - BNC coaxial - AES - Optical fiber

 

 

If I am planning on only using the I2s input on the Holo then it would make no sense to upgrade the Holo's internal clock?

 

Sorry to sound so rudimentary but sometimes this information needs to be broken down in little bit size pieces. 

 

These questions for me involve integrating all this with clarity:

Holo Spring

SU-1

External Power supply

HQP 

DSD512

Internal-external clocks

Linux

I2s

 

Lot's to integrate but getting there!  

 

[Altabay]

I noticed the KTE SU-1 is shipping with v2.2 firmware that supports DSD512.  @Bimmer100, is it the same beta version that @ted_b is running?  Is it available for download somewhere?  Also, does it support 768k PCM, and if it does, will it be playable through the Spring DAC?  Spring doesn't do 768k over USB, but I'm hoping it works over I2S.

[ted_b]

2.2 is the firmware I reported on.  And no, 768 doesn't work, at least when I tried it (my SU-1 is broken, my fault, and on the way to Tim for a USB input fix).  I am nicely surprised to hear that 2.2 is shipping.

[Evo-No-Revo]

If I am planning on only using the I2s input on the Holo Spring, would it then make no difference in SQ if I upgraded the Holo's internal clock?

[tboooe]

2 hours ago, ted_b said:

2.2 is the firmware I reported on.  And no, 768 doesn't work, at least when I tried it (my SU-1 is broken, my fault, and on the way to Tim for a USB input fix).  I am nicely surprised to hear that 2.2 is shipping.

I wonder how soon before customers with the standard SU-1 will get the update.

[tboooe]

42 minutes ago, Evo-No-Revo said:

If I am planning on only using the I2s input on the Holo Spring, would it then make no difference in SQ if I upgraded the Holo's internal clock?

As I understand it, the i2s input gets the clock from whatever the upstream device is.  So yes in that case upgrading the Holo clock won't improve anything.

[scan80269]

55 minutes ago, tboooe said:

As I understand it, the i2s input gets the clock from whatever the upstream device is.  So yes in that case upgrading the Holo clock won't improve anything.

@tboooe is correct.

 

I just temporarily pulled the 22.5792MHz crystal off my Spring DAC.  The USB input will not play 44.1/88.2/176.4/352.8K PCM content (display shows "------"), or any DSD from DSD64 to DSD512, but 48/96/192/384K PCM content can still play since I didn't remove the 24.576MHz crystal.

 

In this condition, the Spring I2S input driven by Singxer SU-1 can play all sampling rates up to 384K and DSD256 (soon to be DSD512 native with upcoming SU-1 firmware upgrade), the coax and AES/EBU inputs play up to 192K.  Sanpling frequencies of 441./88/176.4/352.8K are completely unaffected by the crystal absence with all inputs except USB..

 

This basically means the Spring DAC uses its two internal audio clock references for the USB input only.  For the I2S input, the Spring uses the MCLK sent by the I2S source (SU-1 in my case).  For AES/coax/Toslink inputs the Spring performs audio clock & data recovery without depending on the internal crystal references.

 

Upgrading the Spring DAC internal clocks will affect the USB input but not any of the other inputs, including I2S.

 

I hope this clears things up a bit for everybody.

 

 

 

[earnmyturns]

With a SU-1 is there any reason to use USB directly into the Spring? Currently burning-in my new Spring through USB with varied PCM sample rates (I don't use DSD) following @Bimmer100's advice to make sure the internal crystals get exercised, but I have an SU-1 in place for when I actually start listening to the Spring.

[scan80269]

47 minutes ago, earnmyturns said:

With a SU-1 is there any reason to use USB directly into the Spring? Currently burning-in my new Spring through USB with varied PCM sample rates (I don't use DSD) following @Bimmer100's advice to make sure the internal crystals get exercised, but I have an SU-1 in place for when I actually start listening to the Spring.

A few folks here on CA (myself included) have heard better sound from the Spring with its I2S input vs. its USB input.  I believe this is where the Singxer SU-1 comes in.  The SU-1 uses Crystek CCHD-575 crystal oscillators which should have higher performance (i.e. lower phase noise) than the run-of-the-mill and rather mediocre crystals used in the Spring for its USB input.

 

To give my Spring as good an I2S source as possible, I've been making modifications to my SU-1.  See the SU-1 thread for more details.

 

When using I2S with Spring, pay close attention to the HDMI cable carrying I2S signals.  The cable should be of high quality and as soon as realistically possible to maintain signal integrity.  Poor I2S signal integrity can undermine or even negate the advantage of the higher performing external clocks coming from the I2S.

 

[Evo-No-Revo]

14 hours ago, scan80269 said:

@tboooe is correct.

 

I just temporarily pulled the 22.5792MHz crystal off my Spring DAC.  The USB input will not play 44.1/88.2/176.4/352.8K PCM content (display shows "------"), or any DSD from DSD64 to DSD512, but 48/96/192/384K PCM content can still play since I didn't remove the 24.576MHz crystal.

 

In this condition, the Spring I2S input driven by Singxer SU-1 can play all sampling rates up to 384K and DSD256 (soon to be DSD512 native with upcoming SU-1 firmware upgrade), the coax and AES/EBU inputs play up to 192K.  Sanpling frequencies of 441./88/176.4/352.8K are completely unaffected by the crystal absence with all inputs except USB..

 

This basically means the Spring DAC uses its two internal audio clock references for the USB input only.  For the I2S input, the Spring uses the MCLK sent by the I2S source (SU-1 in my case).  For AES/coax/Toslink inputs the Spring performs audio clock & data recovery without depending on the internal crystal references.

 

Upgrading the Spring DAC internal clocks will affect the USB input but not any of the other inputs, including I2S.

 

I hope this clears things up a bit for everybody.

 

 

 

Thanks for the clear explanation! 

 

I am looking for a couple of .5m or less I2s cables if anyone has one or two to get rid of.  Please PM if you have something available.

[earnmyturns]

2 hours ago, Evo-No-Revo said:

Thanks for the clear explanation! 

 

I am looking for a couple of .5m or less I2s cables if anyone has one or two to get rid of.  Please PM if you have something available.

KitsuneHiFi has one of those on sale https://kitsunehifi.com/product/generic-i2s-hdmi-cable-0-3m/

[Altabay]

14 hours ago, scan80269 said:

The cable should be of high quality and as soon as realistically possible to maintain signal integrity.

 

 

You must have meant as short as possible.  @scan80269, which HDMI cable are you currently using, and do you plan to upgrade?

 

I'm using the $10 "Quality" 0.3m cable I bought along with the SU-1 from Kitsune.  Intuitively it makes sense to upgrade to prevent the HDMI cable from being the weakest link at the end of the chain, but I'm not sure how much to budget.  As an example, the Wireworld 7 series has several 0.3m choices with $26 Island, $46 Chroma, $100 Ultraviolet, $170 Starlight, $270 Silver Starlight, and $500 Platinum Starlight.  Considering this cable comes after a setup like LPS-1 + ISO REGEN + SU-1 (roughly $1100), or even a dual LPS-1 setup ($1500), what would be the appropriate budget for the HDMI cable?  To me the $170 Starlight seems like the sweet spot, but I'm curious what the other owners of Holo Spring and Singxer SU-1 are thinking.

 

Another question I have is the cable length.  The SU-1 has to be pulled forward to allow enough room for the ISO REGEN connected with the 90-degree USPCB to rest on the Spring DAC chassis.  I think a 0.3m cable could work if the HDMI ports of the DAC and the SU-1 are vertically aligned to minimize the reach, but the cable would have to be flexible enough to avoid putting too much strain on the HDMI ports.  @Superdad, do you have any thoughts on this?

 

0.3m is definitely too short if putting the microRendu behind the ISO REGEN via the hard adapter.  0.5m or 1m will be necessary.  @Superdad, what would you recommend in this situation?  Go for the shortest HDMI cable by connecting the microRendu (or any other NAA) with a regular USB cable because the ISO REGEN takes care of almost all upstream signal quality issues?  Or is there enough benefit to be had from the hard adapter (or even another USPCB!) connection between microRendu and ISO REGEN to overcome the potential loss from using a longer HDMI cable?

[Altabay]

52 minutes ago, earnmyturns said:

KitsuneHiFi has one of those on sale https://kitsunehifi.com/product/generic-i2s-hdmi-cable-0-3m/

 

Just a word of caution, this cable does not have enough flexibility to allow pulling the SU-1 forward to create room for a hard connected REGEN to rest on the Spring DAC chassis.

[earnmyturns]

15 minutes ago, Altabay said:

 

Just a word of caution, this cable does not have enough flexibility to allow pulling the SU-1 forward to create room for a hard connected REGEN to rest on the Spring DAC chassis.

Works for me, but I don't use a Regen. It might help in your system, but I don't fell that I need an additional gadget between a microRendu and the SU-1, since the microRendu already has some of the Regen's circuity.

[Evo-No-Revo]

1 hour ago, Altabay said:

 

Just a word of caution, this cable does not have enough flexibility to allow pulling the SU-1 forward to create room for a hard connected REGEN to rest on the Spring DAC chassis.

If the SU-1 is sitting on top of the Holo Spring by itself, would this cable have the flexibility to go out of the SU-1 into the Holo Spring?