HOLO Audio Spring DAC - R2R DSD512

[hifi25nl]

I have just received the Holo Audio Spring. Thanks to European distributor Magnahifi for the support and suggestions.

Linux kernel needs a patch to enable DSD native. I have already done it for Audiolinux/Archlinux, it can be found here (with Amanero and DSD "silence" patch, realtime kernel) : http://tophifi.it/ftp/packages/kernel/last/

 

The good news is that I have practically no pops (using USB input) switching from PCM to DSD or changing rates in DSD!

 

 

[Superdad]

1 hour ago, tne said:

Alex,

When you refer to the clocks in the Holo as "very poor", what is this opinion based on? 

I am running mine primarily with AES input from a Mutec MC3+ USB with PCM/192kHz. It is sounding pretty good this way. 

 

 

 

Hi Thomas,

By no means did I intend to denigrate the Holo Spring!  I bought a full "Level 3" and have been enjoying it.

But the clocks in it are just $0.50 generic Asian items (I looked them up and there was no reference at all to them being low-jitter/low phase-noise pieces), and even Tim at Kitsune indicated that Holo said they put all the effort and money into the rest of the design and that at the Spring's price point (remember it starts at about $1,500) they did not have the budget for nicer clocks.  He also said that the follow-on model, the "May" DAC would have better clocks.

That's all I know.

 

Best,

--Alex C.

[ted_b]

1 hour ago, hifi25nl said:

I have just received the Holo Audio Spring. Thanks to European distributor Magnahifi for the support and suggestions.

Linux kernel needs a patch to enable DSD native. I have already done it for Audiolinux/Archlinux, it can be found here (with Amanero and DSD "silence" patch, realtime kernel) : http://tophifi.it/ftp/packages/kernel/last/

 

The good news is that I have practically no pops (using USB input) switching from PCM to DSD or changing rates in DSD!

 

 

Piero, Hi.  I saw that in the AudioLinux notes, nice.  I don't need them cuz I use the Holo with a microRendu, which uses it's own patch for NAA playback in native, but pops persist (for initializing DSD only, not inter-track clicks, etc).  I hope to test some beta stuff soon for the pops in NAA mode.  But nice to know native pop-less DSD is supported in AudioLinux direct (from AudioLinux server to dac). 

[tne]

Thanks, Alex. It was simply my lack of knowing about the clock. My intended question was concerning input from a reclocker like the Mutec (over AES) does this mitigate any issues that may be present regarding the not-top-quality internal clocks of the DAC? 

 

 

48 minutes ago, Superdad said:

Hi Thomas,

By no means did I intend to denigrate the Holo Spring!  I bought a full "Level 3" and have been enjoying it.

But the clocks in it are just $0.50 generic Asian items (I looked them up and there was no reference at all to them being low-jitter/low phase-noise pieces), and even Tim at Kitsune indicated that Holo said they put all the effort and money into the rest of the design and that at the Spring's price point (remember it starts at about $1,500) they did not have the budget for nicer clocks.  He also said that the follow-on model, the "May" DAC would have better clocks.

That's all I know.

 

Best,

--Alex C.

 

[scan80269]

On ‎3‎/‎21‎/‎2017 at 11:57 AM, barrows said:

BTW, the NDK oscillators have their pads at their corners, so they will often fit on a PCB designed for a larger oscillator.  Usually, if there is not enough room for the Crystek 575, the NDKs will fit.

Barrows, you are probably right on.  Judging by a magnified pic of the Spring DAC main board, it looks like the two crystal oscillators sitting near the AK4137EQ ASRC chip are of the 5mm x 3.2mm form factor.  The NDK NZ2520SD oscillators are 2.5mm x 2mm, with pads at the corners like you said, so I'm reasonably confident they can be soldered properly.  There's another 24MHz oscillator near the XMOS chip on the USB receiver daughterboard that can be dealt with similarly.

 

I have not determined whether all the oscillators are powered by +3.3V, and this needs to be confirmed before I proceed to ordering replacement oscillators with low phase noise.

 

[Altabay]

4 hours ago, ted_b said:

Piero, Hi.  I saw that in the AudioLinux notes, nice.  I don't need them cuz I use the Holo with a microRendu, which uses it's own patch for NAA playback in native, but pops persist (for initializing DSD only, not inter-track clicks, etc).  I hope to test some beta stuff soon for the pops in NAA mode.  But nice to know native pop-less DSD is supported in AudioLinux direct (from AudioLinux server to dac). 

 

Hi Ted, can you clarify what beta stuff you're hoping to test?  Is there an upcoming beta of microRendu update that fixes the native DSD initialization pop?

[ted_b]

Altabay,

Hi.  No, I meant for another part of the path, the AudioLinux OS end, and how it works with HQplayer embedded as the server (and microRendu as NAA).  But I'm sure, at some part in the signal path someone will find a stop to this.  It's quite annoying in an otherwise almost perfect audio-friendly Linux world, and I'm a Windows person who knows frighteningly little about Linux. 

[Altabay]

4 hours ago, ted_b said:

Altabay,

Hi.  No, I meant for another part of the path, the AudioLinux OS end, and how it works with HQplayer embedded as the server (and microRendu as NAA).  But I'm sure, at some part in the signal path someone will find a stop to this.  It's quite annoying in an otherwise almost perfect audio-friendly Linux world, and I'm a Windows person who knows frighteningly little about Linux. 

 

Awwwh, you had my hopes up, but that's ok.  I finally caved in last night and changed to Windows NAA to enjoy DSD512 safely.  The pop is still there but the volume level is much, much lower, more like a tick than a pop.  Hopefully a solution will be found soon for microRendu.

[Forehaven]

11 hours ago, ted_b said:

Altabay,

Hi.  No, I meant for another part of the path, the AudioLinux OS end, and how it works with HQplayer embedded as the server (and microRendu as NAA).  But I'm sure, at some part in the signal path someone will find a stop to this.  It's quite annoying in an otherwise almost perfect audio-friendly Linux world, and I'm a Windows person who knows frighteningly little about Linux. 

Fingers crossed Ted!  

[scan80269]

On 3/22/2017 at 1:16 PM, tne said:

Thanks, Alex. It was simply my lack of knowing about the clock. My intended question was concerning input from a reclocker like the Mutec (over AES) does this mitigate any issues that may be present regarding the not-top-quality internal clocks of the DAC? 

 

 

 

Not Alex, but here are some thoughts on this topic:

 

The extent of the impact from DAC internal clocks (good vs. mediocre) is likely implementation dependent.  With AES (and also S/PDIF coax or optical), the clock is embedded with the data via Biphase mark code modulation.  The DAC being the receiver (sink) has to perform clock recovery and synchronize to the source (Mutec in your case).  One or more PLL (phase locked loops) is often involved.  How well the PLL locks to the recovered clock is dependent on implementation.  Some designs use a local clock for the PLL to use as a starting point, but this is not the clock being sent to the digital-to-analog converter.  Recovering a clean (low jitter) clock from AES or S/PDIF has always been a technical challenge, and I suspect a local clock reference with its own jitter contribution will not help matters.

 

It is difficult to predict how better (e.g. lower phase noise) local clock references can improve the AES clock recovery function of a particular DAC.  Since I'm curious about it, I'm prepared to experiment on my Holo Audio Spring DAC to assess any change to the performance of the AES and S/PDIF inputs.

 

Separately, the I2S (HDMI) input of the Spring does not depend on the local clock references, so changing those oscillators should have no effect in the sound with I2S input.  What can affect the sound in this mode is the I2S transmission signal integrity, which is influenced by the source (e.g. my Singxer SU-1), the carrier (HDMI cable) and the sink (Spring I2S HDMI input).  Among these, the one the user has the most control over is of course the HDMI cable.

 

[tne]

19 hours ago, scan80269 said:

Not Alex, but here are some thoughts on this topic:

 

The extent of the impact from DAC internal clocks (good vs. mediocre) is likely implementation dependent.  With AES (and also S/PDIF coax or optical), the clock is embedded with the data via Biphase mark code modulation.  The DAC being the receiver (sink) has to perform clock recovery and synchronize to the source (Mutec in your case).  One or more PLL (phase locked loops) is often involved.  How well the PLL locks to the recovered clock is dependent on implementation.  Some designs use a local clock for the PLL to use as a starting point, but this is not the clock being sent to the digital-to-analog converter.  Recovering a clean (low jitter) clock from AES or S/PDIF has always been a technical challenge, and I suspect a local clock reference with its own jitter contribution will not help matters.

 

It is difficult to predict how better (e.g. lower phase noise) local clock references can improve the AES clock recovery function of a particular DAC.  Since I'm curious about it, I'm prepared to experiment on my Holo Audio Spring DAC to assess any change to the performance of the AES and S/PDIF inputs.

 

Separately, the I2S (HDMI) input of the Spring does not depend on the local clock references, so changing those oscillators should have no effect in the sound with I2S input.  What can affect the sound in this mode is the I2S transmission signal integrity, which is influenced by the source (e.g. my Singxer SU-1), the carrier (HDMI cable) and the sink (Spring I2S HDMI input).  Among these, the one the user has the most control over is of course the HDMI cable.

 

 

Many thanks for your clear explanation, and looking forward to learning the results of your experiments.

[hols]

On ‎2017‎年‎3‎月‎24‎日 at 8:49 AM, scan80269 said:

Not Alex, but here are some thoughts on this topic:

 

The extent of the impact from DAC internal clocks (good vs. mediocre) is likely implementation dependent.  With AES (and also S/PDIF coax or optical), the clock is embedded with the data via Biphase mark code modulation.  The DAC being the receiver (sink) has to perform clock recovery and synchronize to the source (Mutec in your case).  One or more PLL (phase locked loops) is often involved.  How well the PLL locks to the recovered clock is dependent on implementation.  Some designs use a local clock for the PLL to use as a starting point, but this is not the clock being sent to the digital-to-analog converter.  Recovering a clean (low jitter) clock from AES or S/PDIF has always been a technical challenge, and I suspect a local clock reference with its own jitter contribution will not help matters.

 

It is difficult to predict how better (e.g. lower phase noise) local clock references can improve the AES clock recovery function of a particular DAC.  Since I'm curious about it, I'm prepared to experiment on my Holo Audio Spring DAC to assess any change to the performance of the AES and S/PDIF inputs.

 

Separately, the I2S (HDMI) input of the Spring does not depend on the local clock references, so changing those oscillators should have no effect in the sound with I2S input.  What can affect the sound in this mode is the I2S transmission signal integrity, which is influenced by the source (e.g. my Singxer SU-1), the carrier (HDMI cable) and the sink (Spring I2S HDMI input).  Among these, the one the user has the most control over is of course the HDMI cable.

 

Since the I2S input of the Holo Spring can give better SQ then can I ask is there any way that one can output I2S from a computer? Is the audio-gd I2S card only good for raspberry Pi or is it also compatible with other desktop computers? Using Singxer SU-1 or Pink Faun bridge actually are only converting USB to I2S and theoretically is not as good as I2S direct from the source without conversion.

[scan80269]

2 hours ago, hols said:

Since the I2S input of the Holo Spring can give better SQ then can I ask is there any way that one can output I2S from a computer? Is the audio-gd I2S card only good for raspberry Pi or is it also compatible with other desktop computers? Using Singxer SU-1 or Pink Faun bridge actually are only converting USB to I2S and theoretically is not as good as I2S direct from the source without conversion.

The Singxer SU-1 DDC converts from USB to I2S (and other formats), but I don't think the Pink Faun bridge card does the same.  It is a PCIe add-in card with a C-Media HDAudio chip on it.  The card converts the single-ended I2S signals from the audio chip to differential format then runs them to an HDMI connector for cable connection to a DAC with I2S-HDMI input.  The card has no USB input.

 

If you wish to bypass USB and drive your DAC directly using I2S from a computer, then the Pink Faun bridge card is what you want.  It is essentially a PC sound card with I2S-HDMI output.

 

Keep in mind that even in differential form carried by HDMI (or Ethernet) cable, I2S signal integrity can easily degrade over long cable lengths.  It's best to keep the HDMI cable used for transporting I2S to DAC as short as possible, for example, 0.3m, 1 foot or even shorter.  This of course will force your I2S -equipped computer and DAC to sit close to each other, which may not  be very practical.  Singxer SU-1 allows the USB cable to go a bit longer while keeping the I2S-HDMI cable short,  Just place the SU-1 close to the DAC.  SU-1 and Pink Faun card represent different tradeoffs between sound quality and convenience.  You decide which is best for you.

 

[wouterk]

Have you compared these 2 options? Singxer sounds good with short cable to Holo Audio Spring DAC

[hifi25nl]

I don't have the Singxer, but I have compared Holo internal USB v/s PinkFaun i2s card. In this second case the sound is a lot better. More bass, instruments more real, high frequencies more sweet. I was using the special (huge) i2s 1m cable form the same company. 

I am making also a personal custom Usb to i2s interface capable of DSD512 native (ready for DSD1024). I will post the results when some components I am waiting  will arrive.

[despinos]

35 minutes ago, hifi25nl said:

I don't have the Singxer, but I have compared Holo internal USB v/s PinkFaun i2s card. In this second case the sound is a lot better. More bass, instruments more real, high frequencies more sweet. I was using the special (huge) i2s 1m cable form the same company. 

I am making also a personal custom Usb to i2s interface capable of DSD512 native (ready for DSD1024). I will post the results when some components I am waiting  will arrive.

With the Pinkfaun i2s card costing about 275 Euros and their i2s cable costing about 800 euros I think it's clear why most Holo i2s input users prefer the Singxer instead

[despinos]

7 hours ago, hols said:

Since the I2S input of the Holo Spring can give better SQ then can I ask is there any way that one can output I2S from a computer? Is the audio-gd I2S card only good for raspberry Pi or is it also compatible with other desktop computers? Using Singxer SU-1 or Pink Faun bridge actually are only converting USB to I2S and theoretically is not as good as I2S direct from the source without conversion.

A possible alternative to the Pinkfaun card may be using an Asus Essence Stx II. That is a mother-daughter 2 boards combo, linked with a detachable ribbon. I think (read about it elsewhere) that the pinouts at the "mother" (main) Essence STX card are in i2s "format" so in theory you could take the i2s signals from those pins with a custom built cable. As with all i2s solutions, quality will/may limit the cable length.

 

Pinkfaun sells a 100cm i2s cable, so maybe a similar DIY cable is feasible. Edit: if as previously said (pinkfaun) "card converts the single-ended I2S signals from the audio chip to differential format then runs them to an HDMI connector" then it seems that the ability to pass the i2s signal a 100cm lenght is not actually thanks to that expensive Pinkfaun cable, but rather to the "differential format" applied by the card. However, can that "differential i2s format" be used with a DIY cable and the HOLO Dac without more additions?

 

 

Edit: "stealing" i2s signals from soundcards is mentioned in various forums, for example:

http://www.guru3d.com/articles-pages/asus-xonar-essence-st-deluxe-review,14.html

" I2S signals: This is for the experience modders out there, the ST allow you modders with I2S DAC's to access the needed signals directly from the pin header. You have the LR Clock, Bit and master signals present."

However, that alternative (i2s from a soundcard other than the pinkfaun) will bring into question the "sound quality" of the particular sound card, and maybe makes more sense than using a Pinkfaun card only if you already have a suitable Asus or similar card.

 

 

[hols]

7 hours ago, hifi25nl said:

I don't have the Singxer, but I have compared Holo internal USB v/s PinkFaun i2s card. In this second case the sound is a lot better. More bass, instruments more real, high frequencies more sweet. I was using the special (huge) i2s 1m cable form the same company. 

I am making also a personal custom Usb to i2s interface capable of DSD512 native (ready for DSD1024). I will post the results when some components I am waiting  will arrive.

That would be very interesting and I would be most eager to know the results. I am using HQplayer and DSD512 native sent to USB of the Holo. I have also tried the Singxer sent to I2S of Holo and I agree that the I2S has a certain 'rightness'  but it is only up to Dop dsd256. That is why I am interested to explore how to send I2S to Holo so that it can play dsd512. Pink Faun is only 32/192 and not capable of DSD512 and it is only for Window. That is why I am not so interested in Pink Faun. I am using Linux Debian 9 and I have also patched the kernel so there is no pop sound on changing from PCM to DSD or between different files. 

[hols]

6 hours ago, despinos said:

A possible alternative to the Pinkfaun card may be using an Asus Essence Stx II. That is a mother-daughter 2 boards combo, linked with a detachable ribbon. I think (read about it elsewhere) that the pinouts at the "mother" (main) Essence STX card are in i2s "format" so in theory you could take the i2s signals from those pins with a custom built cable. As with all i2s solutions, quality will/may limit the cable length.

 

Pinkfaun sells a 100cm i2s cable, so maybe a similar DIY cable is feasible. Edit: if as previously said (pinkfaun) "card converts the single-ended I2S signals from the audio chip to differential format then runs them to an HDMI connector" then it seems that the ability to pass the i2s signal a 100cm lenght is not actually thanks to that expensive Pinkfaun cable, but rather to the "differential format" applied by the card. However, can that "differential i2s format" be used with a DIY cable and the HOLO Dac without more additions?

 

 

Edit: "stealing" i2s signals from soundcards is mentioned in various forums, for example:

http://www.guru3d.com/articles-pages/asus-xonar-essence-st-deluxe-review,14.html

" I2S signals: This is for the experience modders out there, the ST allow you modders with I2S DAC's to access the needed signals directly from the pin header. You have the LR Clock, Bit and master signals present."

However, that alternative (i2s from a soundcard other than the pinkfaun) will bring into question the "sound quality" of the particular sound card, and maybe makes more sense than using a Pinkfaun card only if you already have a suitable Asus or similar card.

 

 

I have the old version of Asus STX  soundcard and I believe the SQ is not in the same league as all the others we are talking about. 

[GUTB]

Someone correct me if I'm wrong:

 

There is NO Linux solution for DSD512 available until Amanero fixes their drivers.

 

There are no XMOS solutions that can handle DSD512.

 

The STANDARD Amanero board has broken DSD512 (noise present).

[ted_b]

12 minutes ago, GUTB said:

Someone correct me if I'm wrong:

 

There is NO Linux solution for DSD512 available until Amanero fixes their drivers.

 

There are no XMOS solutions that can handle DSD512.

 

The STANDARD Amanero board has broken DSD512 (noise present).

OK, then, here is where you are wrong (this is at least the second time I've corrected you and this misinformation):

1)  the microRendu is Linux and does DSD512 natively with several Dacs, including the Holo

2)  Running AudioLinux you can do DSD512 directly (no NAA) into the dacs like the Holo, pop-free in fact.

3)  I own two XMOS products that do native DSD512 (Holo dac, Singxer SU-1).

4)  Yes, in the case of Amanero, they need to fix their Linux drivers, but Amanero dacs like T+A Dac 8 DSD does DSD512 via ASIO (Windows)

[Nsxturbo]

Hey Ted,

 

Which driver are you using to get the Singxer SU-1 to do DSD512? 

 

I get DSD512 fine with the HOLO driver into the Spring's USB input, but can only do DSD256 on the Singxer.

 

Do you use the Holo driver for the Singxer XMOS also?

 

I would love to be able to compare DSD512 on the USB & the I2s inputs of the Spring as I'm using the Uptone LPS-1 supercapacitor supply to run the Singxer with good results with the Itona on the USB input.

 

Todd

[ted_b]

Yes, this firmware must use the Holo's own driver.   You can only do DSD256 with the Singxer cuz you don't have this firmware; that is what this firmware does!

 

I will try to describe the I2S vs USB over the next few days, but I have not modified the Singxer ps like you have.  I'm sure it sounds great, and will likely improve at DSD512.  The firmware will be out soon enough.

[Nsxturbo]

Hey Ted,

 

 

Sorry I didn't quite understand your reply. Did you mean you have a not yet publicly released firmware for the Singxer that allows it to do DSD512? or are you updating the Singxer XMOS firmware with the Holo DSD512 XMOS hardware that we're using on the Spring?

 

Todd

 

 

 

 

[ted_b]

Firmware and driver software are two different things.  The unreleased firmware (2.20) that is installed on the Singxer SU-1 to get it to do DSD512 is not yet released, and still being tested and fixed for certain bugs.  The existing Holo Spring drivers are production and have been out there for some time.  It is those drivers (Linux and Windows) that are to be used with the SU-1 (once updated) to do native DSD, in this case DSD512.