HOLO Audio Spring DAC - R2R DSD512

[guymrob]

Thanks Ted_B, is the latest unit(firmware) were able to DSD512 natively using latest Windows driver provided by Holo Audio Springs? I heard in the forum about PCM 768k but not sure this is supported.

[guymrob]

The NOS mode is the most talk about in this forum. When playing back a low sample like 44.1k without OS, does this present itself more noise above the 22k spectrum? Most off selves DACs from manufacturers used a default 8x OS to shift the sampling noise to higher band thus making it easier to filter off the noise.

[ted_b]

Thanks Ted_B, is the latest unit(firmware) were able to DSD512 natively using latest Windows driver provided by Holo Audio Springs? I heard in the forum about PCM 768k but not sure this is supported.

 

Feel free to read my review here. Both Linux (ie microRendu) and Windows supports DSD512 natively (i.e no DoP needed). It's my go-to.

[lmitche]

Feel free to read my review here. Both Linux (ie microRendu) and Windows supports DSD512 natively (i.e no DoP needed). It's my go-to.

Ted, is the interface clean? Meaning do you have any loud pops or ticks with the Holo Spring in DSD 512 native?

[ted_b]

Ted, is the interface clean? Meaning do you have any loud pops or ticks with the Holo Spring in DSD 512 native?

 

Larry, to be frank I can't find any native DSD Linux implementation (via, say, microRendu) that doesn't have loud pops at the start of playing any DSD format, whether upsampled or not. If the player (HQPlayer in my case) doesn't stop, then all is fine after the first pop (which i control via volume for the first few seconds). I've told everyone I know about this but no one seems to have a fix. If I find other songs to play I add then to the end. I pretty much stay in DSD512 mode, but invariably I have to stop the playback for some reason, and am used to it enough to remember to turn down the volume at the start again.

[ericuco]

Larry, to be frank I can't find any native DSD Linux implementation (via, say, microRendu) that doesn't have loud pops at the start of playing any DSD format, whether upsampled or not. If the player (HQPlayer in my case) doesn't stop, then all is fine after the first pop (which i control via volume for the first few seconds). I've told everyone I know about this but no one seems to have a fix. If I find other songs to play I add then to the end. I pretty much stay in DSD512 mode, but invariably I have to stop the playback for some reason, and am used to it enough to remember to turn down the volume at the start again.

 

My DAC (TPA Buffalo III SE) with the JLSounds USB board does not suffer from loud pops when playing native DSD via Linux, in my case microRendu.

 

I used to have this problem (actually I got the loud pop after an album had finsihed, not at the start) when I was forced to use DoP but the latest firmware for the USB board solved all "pop" related issues whether native DSD or DoP versions and provided support for native DSD (no more DoP).

 

On some albums, I will get a slick "tick" between tracks.

[lmitche]

Thanks Ted, I was hoping for a different answer but am not surprised. With HQplayer on Windows upsampling DSD512 native to the IFI microIDSD, if I am disciplined I can boot and play music without any loud pops, and only have to put up with ticks when track resolution changes. The most important thing is wait until the DAC is back in PCM mode once DSD play is finished. I can hear this mode switch as it causes a small tick. Once done, HQplayer operations are safe.

 

I don't use an NAA, and when I do it's on Linux and always ends in disaster. Actually anything Linux ends in disaster.

 

The T+A DSD DAC 8 is completely clean with native DSD on Windows, so it can be done.

 

I dread trying out a new DAC. The Holo Spring DAC is interesting, but I'll wait until it is better integrated.

[ted_b]

Thanks Ted, I was hoping for a different answer but am not surprised. With HQplayer on Windows upsampling DSD512 native to the IFI microIDSD, if I am disciplined I can boot and play music without any loud pops, and only have to put up with ticks when track resolution changes. The most important thing is wait until the DAC is back in PCM mode once DSD play is finished. I can hear this mode switch as it causes a small tick. Once done, HQplayer operations are safe.

 

I don't use an NAA, and when I do it's on Linux and always ends in disaster. Actually anything Linux ends in disaster.

 

The T+A DSD DAC 8 is completely clean with native DSD on Windows, so it can be done.

 

I dread trying out a new DAC. The Holo Spring DAC is interesting, but I'll wait until it is better integrated.

 

? Just like the T+A (which you haven't yet heard in native DSD) the Holo plays native DSD fine via Windows ASIO, whether NAA or not. The jury is out until Amanero allows for microRendu native DSD. Only then we can see if its dac-related or microRendu related or Linux in general (although as Eric says, it can be done). But my bet is it is not Holo, as others non-Holo users report the same pops. As I said, it is no real issue anymore with me cuz I am disciplined with the muting and am primarily letting HQplayer run in DSD512 ad nauseum.

[JohnSwenson]

? Just like the T+A (which you haven't yet heard in native DSD) the Holo plays native DSD fine via Windows ASIO, whether NAA or not. The jury is out until Amanero allows for microRendu native DSD. Only then we can see if its dac-related or microRendu related or Linux in general (although as Eric says, it can be done). But my bet is it is not Holo, as others non-Holo users report the same pops. As I said, it is no real issue anymore with me cuz I am disciplined with the muting and am primarily letting HQplayer run in DSD512 ad nauseum.

 

My take is that this is really the DAC's job, the problem is that a DSD "stream" with no data causes the output to go to one of the power rails, creating the loud pop, in PCM no data causes the output to go to ground. This is such an inherent issue that the DAC should take care of it.

 

A DAC NOT taking care of this is like wiring your house with 20 gauge wire and not having any circuit breakers and just saying "its up to the user to make sure they don't plug in a heavy load"

 

The problem is that if a DAC doesn't deal with this properly ANY interruption of the data causes the POP. When the driver connects to a DAC it either has to start IMMEDIATELY playing music, or fake out the DAC by providing its own fake DSD stream with alternating ones and zeros so the output stays at ground until the OS starts delivering music.

 

I personally don't think the drivers should have to do this, I think it is very remiss of manufacturers to sell DACs that will blow up your speakers if you don't use just exactly the right drivers, software has bugs, drivers break when OS's change, that is a fact of life, DACs should take that into account.

 

John S.

[Miska]

My take is that this is really the DAC's job, the problem is that a DSD "stream" with no data causes the output to go to one of the power rails, creating the loud pop, in PCM no data causes the output to go to ground. This is such an inherent issue that the DAC should take care of it.

 

This may go wrong even with PCM. For example some ASUS sound cards kept output the last sent PCM sample when the playback was stopped. If that sample wasn't zero, DC was coming out...

 

The problem is that if a DAC doesn't deal with this properly ANY interruption of the data causes the POP. When the driver connects to a DAC it either has to start IMMEDIATELY playing music, or fake out the DAC by providing its own fake DSD stream with alternating ones and zeros so the output stays at ground until the OS starts delivering music.

 

I personally don't think the drivers should have to do this, I think it is very remiss of manufacturers to sell DACs that will blow up your speakers if you don't use just exactly the right drivers, software has bugs, drivers break when OS's change, that is a fact of life, DACs should take that into account.

 

Some DAC chips also attempt to do this by triggering the output mute indication pins. However, if DAC manufacturers don't have any output mute relays/circuitry (unfortunately there are such), it of course doesn't help.

 

For example ESS Sabre indicates mute request when there is no data input, same PCM sample is repeating or DSD input bit pattern keeps repeating.

 

But in addition DSD spec requires output to be muted for first 50 ms of DSD data and also for last 50 ms. So the USB interface needs to have at least that 50 ms worth of look-ahead buffer. This is needed in order for the output to settle.

[guymrob]

This is an unresolved issue especially using an USB-DAC; the slight click when playing the next DSD track is obvious. The only way to avoid that is to use I2S interface or use a built-in DAC together with streamer, the interface between the DSP and DAC chip is via I2S allows precise control over signals mute without delay or latency.

[Miska]

This is an unresolved issue especially using an USB-DAC; the slight click when playing the next DSD track is obvious. The only way to avoid that is to use I2S interface or use a built-in DAC together with streamer, the interface between the DSP and DAC chip is via I2S allows precise control over signals mute without delay or latency.

 

Well, I2S doesn't have mute signal or data and I2S is not used for DSD since it is PCM-only interface.

 

However, the USB interfaces in DACs send out I2S, DSD and have separate DSD and mute flag signals, so they have as much full control over mute as anything could possibly have.

 

With clicks between unrelated DSD tracks, you overall have to decide whether you want gapless DSD playback or you want to avoid clicks between tracks. HQPlayer used to handle this between album and playlist transport modes, but since most people seem to use playlist mode and even use Roon or something like that, it is not anymore possible.

[barrows]

Well, I2S doesn't have mute signal or data and I2S is not used for DSD since it is PCM-only interface.

 

However, the USB interfaces in DACs send out I2S, DSD and have separate DSD and mute flag signals, so they have as much full control over mute as anything could possibly have.

 

With clicks between unrelated DSD tracks, you overall have to decide whether you want gapless DSD playback or you want to avoid clicks between tracks. HQPlayer used to handle this between album and playlist transport modes, but since most people seem to use playlist mode and even use Roon or something like that, it is not anymore possible.

 

Jussi: Not sure what you mean by I2S being not for DSD signals... The ESS chip, for example, can easily accept DSD signaling on its I2S inputs, and the Sonore Signature Rendu (for example) can render DSD signals and send them to its (PS Audio spec) LVDS I2S output. It is too bad that the original PS Audio spec puts the masterclock in the source, rather than the DAC though... LVDS I2S could have become relatively "perfect" if it was specced to have the masterclock at the DAC (with flip/flop re-clocking) and send the clock signal back to the source.

[Miska]

Jussi: Not sure what you mean by I2S being not for DSD signals... The ESS chip, for example, can easily accept DSD signaling on its I2S inputs

 

Yes, that auto-detection to automagically change meaning of pins based on detected input patterns is one major source of pain. They really shouldn't be doing it. There is no way to force ESS chip into PCM or DSD mode which would work nicely with the way how ASIO drivers works - explicitly setting output to either format before any data is being sent. Luckily chips from all other manufacturers use this explicit model where firmware will tell over I2C/SPI what will come, upfront.

 

DSD data is sent over three lines:

1) Data left

2) Data right

3) Bit clock

 

While I2S consists of:

1) Interleaved left/right data

2) Word clock (sometimes called L/R clock)

3) Bit clock

4) Master clock (optional)

 

 

and the Sonore Signature Rendu (for example) can render DSD signals and send them to its (PS Audio spec) LVDS I2S output.

 

That has nothing to do with Philips' original I2S standard.

[barrows]

Yes, that auto-detection to automagically change meaning of pins based on detected input patterns is one major source of pain. They really shouldn't be doing it. There is no way to force ESS chip into PCM or DSD mode which would work nicely with the way how ASIO drivers works - explicitly setting output to either format before any data is being sent. Luckily chips from all other manufacturers use this explicit model where firmware will tell over I2C/SPI what will come, upfront.

 

DSD data is sent over three lines:

1) Data left

2) Data right

3) Bit clock

 

While I2S consists of:

1) Interleaved left/right data

2) Word clock (sometimes called L/R clock)

3) Bit clock

4) Master clock (optional)

 

 

 

 

That has nothing to do with Philips' original I2S standard.

 

On LVDS I2S: Hmmm... I would disagree, it is just taking the original version and making a balanced/buffered version for between component transmission.

 

I know nothing of using Window/ASIO, but I have zero problems running my ESS DACs (Buffalo models), with various USB interfaces (Sonore, DIYHiFi), for both PCM/DSD data, and other than the rather ubiquitous small "tic" between tracks, there are no annoying loud pops or other anomalies. My Buffalos get an I2S feed for DSD and PCM with no problems, they auto switch fine without any additional muting. Software players are generally linux/MPD.

[Miska]

I know nothing of using Window/ASIO

 

It is no different from native (non-DoP) DSD on Linux. Switch between PCM and DSD happens before any data streaming takes place.

 

With nice DAC chips, the mode is configured through I2C/SPI to the DAC chip before any audio data streaming takes place. However, with ESS chips this cannot be done, but they'll auto-switch based on detected pin behavior. That causes glitches in the output, unless output is muted for the period when the DAC chip sees data pattern switch.

 

For example Mytek Stereo192-DSD DAC lacks output mute relays and thus always have some glitches in the output when the DAC is powered up/down or there's switch between PCM and DSD. While for example exaSound DACs do have output mute relays.

[guymrob]

I've two experiments, both using an Auralic Aries Mini streamer; one using the internal DAC, a ESS9018KM and the other is routed via USB to an external USB- DAC. When I switch using the internal DAC, playing back DSD, i can't hear any clicks at all and I noticed music kind of fade out when start playing the next track or switch tracks. However, when I switch to external USB-DAC, I can hear clicks when start playing next track or switch tracks. Obviously the built-in DAC chip have much control over mute delay. The Internal CPU can be programmed to send mute signal to gate the analog outputs either in the form solid-state switch or a relay.

[Miska]

I've two experiments, both using an Auralic Aries Mini streamer; one using the internal DAC, a ESS9018KM and the other is routed via USB to an external USB- DAC. When I switch using the internal DAC, playing back DSD, i can't hear any clicks at all and I noticed music kind of fade out when start playing the next track or switch tracks. However, when I switch to external USB-DAC, I can hear clicks when start playing next track or switch tracks. Obviously the built-in DAC chip have much control over mute delay. The Internal CPU can be programmed to send mute signal to gate the analog outputs either in the form solid-state switch or a relay.

 

That sounds like the playback not being gapless between tracks.

 

Of course same can be done with external DACs too. It all depends on the USB interface firmware and mute circuitry inside the DAC. For example DACs that switch modes completely silently for me:

1) exaSound e28

2) TEAC UD-501

3) TEAC NT-503

4) Marantz HD-DAC1

5) T+A DAC8 DSD

6) Resonessence Labs HERUS

7) RME ADI-2 Pro

8) Fostex HP-A8C

 

Gapless playback of unrelated DSD tracks is a separate, different case.

[tboooe]

Well I jumped on the bandwagon and just purchased the Holo Level 3 dac. Unfortunately delivery wont be until late Jan or Feb. Merry xmas to me!

[Superdad]

Well I jumped on the bandwagon and just purchased the Holo Level 3 dac. Unfortunately delivery wont be until late Jan or Feb. Merry xmas to me!

 

Cool tboooe! My new Level 3 has been warming up for a week in my system. Planning to put ears on it for the first time this weekend.

 

 

Sent from my iPad using Computer Audiophile

[tboooe]

Cool tboooe! My new Level 3 has been warming up for a week in my system. Planning to put ears on it for the first time this weekend.

 

 

Sent from my iPad using Computer Audiophile

Awesome! How do you plan to connect it? I am planning to use HDMI via the SU-1 but I will try all the different connection types.

[xiddox]

Has anyone used a Pink Faun I2S bridge to drive the Spring DAC? I have been using mine with a Singxster, but decided to give the PF a try. I put the card in a PC, and installed Windows Server 2012 R2 from scratch. Windows sees the card, the Spring locks onto a 48 kHz signal, but I can't get any sound out of it. Also, I don;t know if this is relevant, but a review of the PF card found that Windows Server 2012 R2 allows up to 32 bit, 19200 kHz, but I can only select up to 24 bit, 19200 kHz.

 

Any clues out there?

 

- richard

[tboooe]

Has anyone used a Pink Faun I2S bridge to drive the Spring DAC? I have been using mine with a Singxster, but decided to give the PF a try. I put the card in a PC, and installed Windows Server 2012 R2 from scratch. Windows sees the card, the Spring locks onto a 48 kHz signal, but I can't get any sound out of it. Also, I don;t know if this is relevant, but a review of the PF card found that Windows Server 2012 R2 allows up to 32 bit, 19200 kHz, but I can only select up to 24 bit, 19200 kHz.

 

Any clues out there?

 

- richard

 

Richard, do you know what the HDMI pinouts are for the PF? You my want to check the Kitsune audio website on the SU-1 page to see what the Spring DAC expects to see on its HDMI input. The SU-1 has user adjustable pinouts to work with the various i2s implementations since there are no standards currently.

[tboooe]

Cool tboooe! My new Level 3 has been warming up for a week in my system. Planning to put ears on it for the first time this weekend.

Sent from my iPad using Computer Audiophile

Well it's the weekend!!! Impressions required!! . Happy new year btw

[xiddox]

Richard, do you know what the HDMI pinouts are for the PF? You my want to check the Kitsune audio website on the SU-1 page to see what the Spring DAC expects to see on its HDMI input. The SU-1 has user adjustable pinouts to work with the various i2s implementations since there are no standards currently.

 

Hi, yes i'm well aware of all that. Both the Spring DAC and my PF card use LVDS signals over the PSaudio spec pinouts, as shown here: https://docs.google.com/spreadsheets/d/1h5PMUBkldkpt1rCnAR4ZHYGZNeCe-vwIFyKWYMZWsX0/htmlview#