HOLO Audio Spring DAC - R2R DSD512

[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.

[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.

[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.

[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.

[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.

[Miska]

Chord DAVE appears to operate its discrete "pulse array DAC" at 5 bits. But like ESS, saying it converts to "PCM" is problematic: question: is a DAC really converting to PCM if the data rate itself is not reduced, that is, say it takes in DSD 2.8 MHz, and then oversamples to a much higher rate (like Chord or Mola Mola) is that really PCM conversion? It seems a matter of semantics at that point to me. If it converted a DSD stream to 352.8 kHz that would be one thing, but...

 

At least Mojo and Hugo seem to be decimating DSD to 352.8k PCM and then converting it back up again. At first I thought Mojo would be doing it to 705.6k since it can also accept that as PCM input, but that doesn't seem to be the case. Unfortunately the decimation digital filter also seems to be quite poor, so it aliases quite a bit of noise down.

 

So just better send as fast PCM as possible to Chord.

[Miska]

What follows is just excuses/apology as to why it doesn't really do native DSD (i.e., most other DACs don't either).

 

The fact is this: R2R ladders can't deal with 1-bit streams because it requires multiple bits to compare with in order to generate the analog signal.

 

There's quite a number of DACs that can do direct DSD conversion. Since those are delta-sigma DACs and not R2R ladders, it is just matter of sending the bitstream to the actual conversion element network. Examples of such DAC chips can be found for example from TI/BB, AKM, CirrusLogic/Wolfson. Plus of course now various discrete implementations.

[Miska]

What I read on their site is that it converts DSD to PCM. Which makes sense as R2R ladders work by comparing bits of a digital audio stream in order to produce an analogue signal, meaning that using this method to decode DSD is impossible. The separate native DSD dual ladder board blurb is simply a LIE or at least misinformation by someone's bad translation.

 

I gave it a short thought when I heard about it and I could immediately think of a way how to turn R2R ladder into a typical delta-sigma (DSD) DAC if it is taken into account at the design phase. It either needs a small rearrangement where the switch is placed in the network, or alternatively way to switch the summing network out and replace it with just plain I/V converter. Then rest is about data arrangement when sending it to the conversion which is completely bit-perfect operation. Then it becomes just like for example my DSC1 DAC design which uses 32 conversion elements. But one could as well use 24 like dCS does.

[Miska]

What I read on their site is that it converts DSD to PCM. Which makes sense as R2R ladders work by comparing bits of a digital audio stream in order to produce an analogue signal, meaning that using this method to decode DSD is impossible. The separate native DSD dual ladder board blurb is simply a LIE or at least misinformation by someone's bad translation.

 

I gave it a short thought when I heard about it and I could immediately think of a way how to turn R2R ladder into a typical delta-sigma (DSD) DAC if it is taken into account at the design phase. It either needs a small rearrangement where the switch is placed in the network, or alternatively way to switch the summing network out and replace it with just plain I/V converter. Then rest is about data arrangement when sending it to the conversion which is completely bit-perfect operation. Then it becomes just like for example my DSC1 DAC design which uses 32 conversion elements. But one could as well use 24 like dCS does.

 

I don't know what the DAC in question does, but at least I know precisely how I would personally do it if I wanted to.

[Miska]

I just installed ASIO4ALL and pointed it at the Pink Faun device, but NAA crashes when I start playing music. I've had enough for one night. I'll take a closer look and try again tomorrow. If I can't get it working quickly, I'll probably install Linux on another partition and see if I can get that working.

 

If ASIO4ALL expects to get a window handle and doesn't check, then it may crash because it'll get NULL with the NAA binary (because it doesn't have a window).

 

Linux (minimal, without any GUI) is generally much better option. Windows or macOS for a NAA is kind of strange beast because both OS are so bloated. But sometimes it is necessary from driver support perspective. Pink Faun is based on C-Media's chip which I think should work on Linux too.

[Miska]

Wait, I recall the Pink Faun didn't support DSD -- and they had a write-up on thier page about how DSD sucks, etc. Have they added DSD support?

 

I2S is a PCM-only interface in first place. Since they at least now seem to use C-Media chip that is limited to 192k PCM you can get DSD64 over DoP or if the DAC supports also DSD128 over "2wire" mode (requires two I2S lanes for stereo).

[Miska]

Okay fine, I agree there are two resistor ladders now. But HOW does this PCM ladder network handle 1-bit streams? I just don't buy it. Does it transform into a virtual DS DAC similar to how Miska suggested?

 

Based on that above description, it doesn't. There seems to be a second network that is the DSD converter. Download my schematics from the link above and you can see one way to do it.

 

You can make quite a number of variations around the topic, for example the TI/BB DAC chips give you four different conversion configurations to choose from.

[Miska]

SSE4.2 is needed. But for hardware older than that, the 32-bit binaries/OS should work...

[Miska]

Thanks Miska. Is that what the MicroRendu runs?

 

No, microRendu is completely different hardware (ARM Cortex-A9).

[Miska]

Then i found that Jussi has not included a 32-bit version of networkaudiod for xenial, so I installed the one for stretch.

 

Yes, I don't have 32-bit Xenial installed anywhere yet. But I can probably update my old Trusty virtual machine and build a Xenial-specific package.

 

Everything looks good: networkaudiod now runs and is seen by hqplayer desktop. Only one small hiccup: I am not getting any sound out of my DAC! ... but the DAC is changing samples rates as I change them on hqplayer, so at this point I am going to assume that the lack of sound is due to the fact that I have not yet configured ALSA, and not due to any binary mismatches...!

 

Check volume control on both HQPlayer and your DAC/USB interface, both ALSA and HQPlayer use lowest volume setting for starters for safety reasons. Use for example "alsamixer" to adjust the volume, you can use "aplay -l" to list the devices and then for example "alsamixer -D hw:1" in case your DAC's device is "hw:1". Then you can store the mixer settings as defaults for next boot with "alsactl store".

[Miska]

Hi @Miska, I assume the windows binary is 64-bit; I would be grateful if you could create a 32-bit binary for Windows.

 

Windows package includes both, 32- and 64-bit binaries...

[Miska]

.... of networkaudiod ? Isn't there only a single binary?

 

Just download the ZIP and see what is inside...

[Miska]

protocol error: clSocket::Send(): send(): Unknown error

 

This looks like a network configuration or firewall issue.

 

... which I notice in the NAA thread on this forum, someone else had but overcame it by using the beta of HQplayer, so i am downloading the beta now...

 

Latest version is 3.14.4 release, betas are something prior to 3.14.0 release.

[Miska]

If I understand it correctly it is the manufacturers (Auralic) that need to find the fix rather the DAC manufacturers (Holo Audio Spring)?

 

For DSD to be done correctly, DAC must mute it's output for first and last 50 milliseconds of DSD data. Otherwise you are going to have clicks'n'pops.

[Miska]

But, going from 352.8/384 to (whatever, often MHz rage) will generally not be audible, as any artifacts produced by this OS step are so far beyond the audible range as to not matter

 

It depends on your analog filters. It can still have audible impact due to correlated intermodulation products as explained many times in other threads. Only if you have good and steep enough analog reconstruction filters that remove all the images at 352.8/384k and multiples, you don't have such worries. But so far most of the DAC's I've measured still leave quite a bit of images...

 

If you start from 44.1/24 with 8x oversampling, you need analog filter that rolls off to -144 dB by 330.75 kHz. IOW, you need about 36 dB/octave (6th order) analog filter. And then you need to forget hires, because it needs to begin to roll-off already at about 25 kHz. As a result, the phase response will look pretty bad too.

[Miska]

I was attempting to keep things a bit simple in speaking generally. Most commercial DACs (but certainly not all) are engineered with pretty strong analog side filters precisely to avoid out of band artifacts causing IM distortions which could be audible.

 

My experience is that there is typically 2nd order analog filter and in some cases 3rd order. But I have not seen anything higher. That is also apparent from the measurement results.

 

For hires that spec I said would need to be 8th order analog filter, that would allow pushing the corner up. IOW, four op-amps per channel, not counting I/V and possible output buffers.

 

what is additionally interesting, and relevant to the NOS discussion, is the variation in DAC designs which are called NOS. some NOS DACs do not have much (if at all) for analog stage filters, and some have very complex analog filters in an attempt to reduce the inherent problems of NOS (like Zanden).

 

Yes, quite many seem to have something like 1st order passive filter or no filter at all (filterless NOS).

[Miska]

What about switching between PCM to DSD or vice-versa?

 

It is the same always, 50 ms mute for first and last of DSD...

 

When switching occurs there's brief period when the OS (Linux or Windows) or and playback program may generates all '0' data

 

That shouldn't happen ever, but for example ESS Sabre will mute output when it detects same byte repeating.

[Miska]

Correct me if I'm wrong, my understanding is hires recording at 352.8/384k (DXD) begins to roll of before half the Nyquist frequency, in this case 176.4/192k. I believe modern digital filter will able to take care the roll off beginning at 176.4/192K all the way down to 352.8/384k, but I'm not sure what is the attenuation factors these digital filters has, how many dB/octave? I'm sure nobody wants want to build a analogue filter to do that, as you mentioned above.

 

For hires recordings you need about 100 kHz bandwidth, so the analog filter -3 dB point is usually placed at 100 kHz. Thus you have the band from 100 kHz to 252.8 kHz to roll-off to -144 dB. Thus you have octave and half, so you need analog filter of about 100 dB/oct to reach perfect reconstruction. That is 17th order filter.

[Miska]

Can you tell me what is different between digital filter in the over sampling block vs the analogue filter right after being converted to analogue? I have an impression that over sampling digital filter has a much greater than -3dB roll off/octave, depending whether is a steep or gentle roll off. Thanks for valuable inputs.

 

Yes, the digital filter can have as steep roll-off as you want. However, you always need an analog filter to remove image frequencies around multiples of the sampling rate. Oversampling digital filters are used to move those image frequencies further away from audio band, so that they can be removed with simpler (lower order) analog filter.

 

If we start with a 0 - 22.05 kHz sweep at 44.1 kHz sampling rate, then oversample it using steep digital filter to 352.8 kHz, this is how the R-2R DAC's output theoretically looks like at 1.4 MHz bandwidth:

 

You wouldn't need analog filter if you'd have infinite output sampling rate.

[Miska]

The loud pop sounds that happens in Linux OS when playing back DSD in native mode as opposed to DoP is caused by the 'digital silence' at the starting of the track. I believed we have found culprit...

 

That silence should be so short that it fits the 50 ms mute period window, so it shouldn't be an issue. But that is good fix to have in any case for technical correctness.