HOLO Audio MAY DAC

[Miska]

34 minutes ago, lpost said:

1.5M at 16 bits sounded a little less fleshed out to me preferring 768k at 20 bits a fair bit more. I believe this is solely based on the USB port being used.

 

Which noise shaper did you use? There shouldn't be notable difference between 16- and 20-bit at 1.5M, or even at 768k.

 

[Miska]

7 hours ago, Diavolo said:

This is a pretty typical way to remove jitter from USB these days.

 

How do you remove jitter from something that doesn't have it's own clock? Asynchronous USB runs off from the DAC's master clock.

 

You need it for S/PDIF and AES/EBU though.

 

7 hours ago, Diavolo said:

Benchmark was using PLL to get jitter <-50ps 20 years ago.

 

That wasn't asynchronous USB, that was the old slave-clocked USB (Audio Class 1.0) where clocking was similar to S/PDIF.

 

7 hours ago, Diavolo said:

Atkinson was blown away by the original Benchmark DAC 1 - USB

 

Which was totally different technology than USB interfaces used today... Clocked in totally different way.

 

[Miska]

6 hours ago, Diavolo said:

Asynchronous communication is defined as transmission of data without the use of an external clock signal. This allows data to be transmitted intermittently rather than in a steady stream

From Audio Misconceptions blog. This doesn't reduce jitter without some buffering.  PLL just reclocks packet data to the DAC, mitigating jitter effectively. 

 

 

That external clock signal is DAC's conversion clock. There is nothing to reclock or nothing to remove jitter from. Because the USB stream doesn't include a clock. Since there's only single clock, there's nothing to reclock. There's no point in reclocking clock with itself.

 

[Miska]

5 hours ago, lpost said:

Does this mean the USB output clock is irrelevant? Could it be something other than 20Mhz and the signal still be received and clocked by the DAC?

 

I'm asking legitimately to learn as I don't know how asynchronous USB is intended to work.

 

USB clock just operates the USB interface itself. It is not related to audio clock. Shoveling data into buffer from where it is clocked out by the DAC conversion clock. Based on that DAC then tells the computer "send me more" or "send me less". There's no link between these two, they are independent. Like Ethernet or computer's clock.

 

[Miska]

13 hours ago, Extreme_Boky said:

But can software affect this wave? Is it done in bursts or is it throttled? The burst might induce periodic jitter, the throttle a constant jitter. 

 

Asynchronous USB Audio Class transfer sends data every 125 µs (8 kHz rate  you can see sometimes leaking to DAC analog output).

 

How much data is sent on this block is controlled by two things; 1) audio format (sample rate, number of bits and number of channels), 2) asynchronous feedback from the DAC.

 

This data ends up in memory buffer at DAC which is then playing it out from there based on it's master clock. If the buffer level is dropping, it tells the computer "send me more", if the buffer level is increasing, it tells the computer "send me less".

 

44.1k base rates are not multiple of the USB clock, so the amount of data per transfer block varies all the time. While 48k base rates are multiple of USB clock and the amount of data per transfer block is more constant with less variation. But generally USB Audio Class is packet based transfer where the packet interval is constant but the amount of data per packet varies.

 

Then there are some DACs that use something else than USB Audio Class and use so called bulk transfer, and they operate in totally different manner. But these also require custom drivers to operate. exaSound DACs are example of such.

 

[Miska]

Just as a practical example, at 44.1k sampling rate, with USB Audio Class asynchronous transfer:

44100 / 8000 = 5.5125 samples per packet on average

176400 / 8000 = 22.050 samples per packet on average

192000 / 8000 = 24 samples per packet on average

 

[Miska]

Just now, Diavolo said:

Yawn,  can I have my money back. You can have your license back. Your software does nothing. 

 

Ehm? What do you mean by doing nothing? Versus your expectation of?

 

[Miska]

2 minutes ago, Diavolo said:

I mean it literally sounds the same with or without it. Serves no purpose. Wastes electricity.  Serves no audible purpose. Months of wasting my time to hear something that's not there. It's snake oil. 

 

I cannot comment on someone hearing or not hearing differences. But at least I've provided objective measurement and analytic data.

 

If you want to call it snake oil, at least providing some objective proof about that would be nice.

 

[Miska]

4 hours ago, GoldenOne said:

Out of curiosity, has anyone tried getting 1.536mhz working from the USB C port on their 2000/3000 series Nvidia GPU?
Not sure what controller they're using but given as it was made explicitly for very demanding VR use I wouldn't be surprised if that worked

 

It is likely Nvidia's own IP block. But in this case it doesn't matter if it's for demanding VR use. It all boils down to implementation details. And I think Nvidia card's Type-C port doesn't support USB at all. Note that "USB Type-C" has Alternate Mode capability and the same physical port can switch between between USB, DisplayPort, Thunderbolt, HDMI, etc functionality. Where the actual signaling is totally different while using the same physical connector. A bit like we now see HDMI for display connectivity and same connector and cabling hardware used for I2S while the two are totally different (just lacking Type-C's capability to negotiate which configuration to use).

 

So it is really case-by-case if it's going to work or not. There's no simple way to tell without testing.

 

[Miska]

On 3/26/2021 at 3:23 PM, lpost said:

Phase invert appears to only be in the desktop version not Embedded.

 

It is on both... Both have the same engine and can be controlled through the same controllers (clients).

 

[Miska]

10 hours ago, Extreme_Boky said:

Well, R-2R DAC converts digital electrical current (current flow through a resistor) into potential difference (across that resistor). This potential differences is also capable of creating a current flow further down the line towards analogue amplification, due to that very same potential difference. Electron flow is redirected, if you wish, from one road into another. No damage done (well, apparat from inaccuracies involved with resistor tolerances...)

 

So, there is no silicon involved during this fundamental conversion process, from current level -> into analogue representation; there are no multiple layers of that silicon required to create a transistor structure for the conversion. Here, we have to open the transistor, move it into its conductive state, and then rely on semiconductive change of state (into conductive) and on movement of electrons / holes through that silicon, to achieve the end-result.

 

The above is a fundamental reason why R-2R sounds better than a chip (silicon).

 

It is not really any different from an SDM DAC. Just the resistor structure is different...

 

Quote

NOS will do the least amount of harm as well.

 

It depends... If you run it at 44.1k, it will do massive amount of harm... Because you are not getting anywhere close to the original analog waveform.

 

[Miska]

7 hours ago, StreamFidelity said:

If I upsample 44.1kHz to 88.2kHz, will the Nyquist frequency be raised from 22.05kHz to 44.1kHz?

 

Yes, instead of images starting from 22.05 kHz, they will now start from 88.2 - 22.05 = 66.15 kHz. So you have inverse frequency spectrum from 66.15 to 88.2 kHz. And forward frequency spectrum from 88.2 to 110.25 kHz. And the same repeats around every multiple of 88.2 kHz.

 

8 hours ago, StreamFidelity said:

The anti-aliasing low-pass filter can then be less steep?

 

The analog one yes. For proper reconstruction of 16-bit source, the analog filter needs to attenuate images by at least 96 dB. For 24-bit source, the analog filter needs to attenuate images by at least 144 dB. First order filter would be 6 dB/oct, second order filter 12 dB/oct, etc.

 

8 hours ago, StreamFidelity said:

And the original analog waveform can be reconstructed better?

 

Yes. In addition, you also need to pay attention to phase shifts the analog filter causes. So you'd generally prefer to have it's -3 dB point around 100 kHz or higher to minimize amount of phase shifts it causes < 20 kHz.

 

8 hours ago, StreamFidelity said:

Or are there other reasons for oversampling?

 

It allows to use noise shaping for the output, which for example with the Holo converter allows drastically improving low level linearity and remove distortion of low level tones and lower distortion of higher level tones.

 

In addition, apodizing filters allow fixing errors in the source content.

 

This is still when sticking to PCM / R2R domain. If we go to SDM (DSD) then it's gets into modulators, different kinds of conversion architectures and such (more flexibility). Although with PCM too you can get into details of different noise shapers and such. So it is not black and white.

 

[Miska]

Using noise shaper like LNS15 (or NS9 or NS5) at high rates like 705.6/768k or 1.4112/1.536M allows you to have way over 20-bit worth of dynamic range in audio band.

 

Even if you need to settle with 16-bit output, like on macOS to reach 1.5M rates, noise shapers allow you to have more digital SNR than the DAC's analog performance allows. IOW, digital noise floor is way below the analog one.

 

In addition, they further linearize the DAC's conversion process, thanks to the analog filters in the DAC output stage.

 

[Miska]

17 minutes ago, scintilla said:

I was looking for whatever thread it was in, because there are so many across so many sites, that you posted some nice pics of how driving the PCM into the Spring/May resistor network this way (20-bit, noise-shaped, high-rate) really cleans up the low-level performance and takes advantage of the inherently low noise of the design. I will be curious to see what the limits of the May design will be fed DSD at the speculative 1024 and 2048x once we have hardware to produce the signals with the best modulators.  Like with the AKM4499, which seems to prefer 256x over 512 (but who knows what they use on-chip for resistors, are they switched capacitors or current sources to save space...), there is probably a sweet spot for driving the May in PCM and DSD as well; that spot that produces the cleanest floor and lowest IMD, etc. You have to be tempted to buy one by now...

 

At the moment May is too expensive for my current R&D budget for buying DACs. The tunings for Spring 2 also match May the same way though. May is just otherwise better. I hope I can obtain a Spring 3 though when such arrives.

 

From testing point of view, DSD1024 with best modulators is not a problem since I can process the test signal conversions offline with HQPlayer Pro.

 

In DSD mode, DSD256 is sweet spot for Spring 2. In PCM mode, the 1.4112/1.536M 20-bit is sweet spot. For May, I would need to have the device to measure if it is the same, but I'd say it likely is.

 

 

AKM chips have traditionally been switched capacitor. Same for Cirrus Logic.

 

[Miska]

On 4/18/2021 at 5:51 PM, Quadman said:

Do you still need to set HQP at -3 if the signal is already -6?

 

Yes, you need to consider difference between digital levels and analog levels...

[Miska]

17 minutes ago, Quadman said:

Thanks Jussi, I realized after I wrote it that its the May that lowers DSD 6 dB, in the PC and HQP there is no DSD output penalty.

 

And it is not straightforward -6 dB, but just 6 dB difference in reference levels. Because DSD can momentarily go to +3.15 dB (DSD), while PCM cannot exceed 0 dBFS. So the level difference is just 3 dB at maximum possible peak level.

 

[Miska]

Looks like left-over solder flux to me... (not washed)

[Miska]

12 hours ago, barrows said:

Any DACs which have similar output voltage form their single ended and balanced outputs.  Any DAC which has exactly half the output voltage from their single ended outputs vs the balanced outputs is almost certainly just using half of the balanced signal.  In my previous post i left out another common way to do balanced to single ended conversion which also results in high performance from the single ended outputs: using a transformer.  The transformer approach is used by Linn in the Klimax DSM, and by Lumin in the X1 DAC for two examples.

 

I much prefer active conversion using differential amplifier stage. I usually combine this with cable capacitance compensated output buffer stage. This also avoids overshoot on square waves at preamp inputs and such, and allows both balanced and unbalanced connections to be used simultaneously and indepdently.

 

Transformers always add plenty of coloration.

 

[Miska]

1 hour ago, Roasty said:

I have a workaround for people running their core on AMD machines.

 

installed Windows 10 on a NUC 

loaded 30,12 firmware

HQPlayer NAA running on the NUC

settings - PCM1.536 on HQPlayer core AMD machine

 

can confirm, 1.536/1.4112M works through a Windows machine as NAA.

 

You can as well just boot the NAA OS image on the NUC. No need for WIndows.

 

[Miska]

14 hours ago, Gavin1977 said:

@Miska  HQPlayer embedded (hqplayer-embedded-4.24.2-x64.7z) software based volume control is not working with PCM material to the Holo May - volume is very quiet.  At max volume you can just about hear music with your ear to the drivers.  Volume control works perfectly, and as expected, in SDM (DSD) mode, volume can also be controlled on MConnect (my control app) whilst in SDM mode - so this is just a problem with PCM.  Any ideas?

 

I also only get PCM upto 768kHz in both embedded and windows versions of HQPlayer using Holos AISO drivers...  advice welcome.

 

Anyone managed 1.536MHz in Windows 10 - in the windows system tray I can only select WASAPI - AISO driver does not appear as a windows option.

 

Looks like I'm stuck with DSD for the moment.

 

Maybe it has digital volume for PCM somewhere. You can check by first running "aplay -l" to list audio devices and then using "alsamixer -c" with corresponding card number after the c -argument.

 

[Miska]

1 hour ago, KenMoreira said:

May is 23/24 bit dac chip.  The spring is 21.

Most delta sigma are 20.

 

Where are you pulling these figures?

 

There's no DAC chip in May or Spring. Both are discrete. Plus a separate DSD mode.

 

Delta-sigma DAC chips are 1 - 6 bits, with 24- or 32-bit inputs to their DSP. Plus various such have direct path for DSD, bypassing the DSP.

 

 

If you send one bit too many with May, your linearity is screwed up and distortion is back. But you can safely go down to 16 bit without losing dynamic range or adding any distortion. So rather send too few bits than too many, with correct kind of noise shaper.

 

 

1 hour ago, dkdali said:

I have a HQPlayer - May dac question: I see that people like @GoldenOne configures HQPlayer to only send 20 bit sound to the May. I thought the May was capable of running 24 and 32 bit. Why not use the full bit resolution?

 

Because it is not physically possible to create R2R ladder that is accurate to such resolutions especially at sampling rates suitable for audio. For this reason you get more accuracy by using less bits, but higher sampling rate.

 

(note, Spring takes in 32-bit samples, but reports it's resolution to be 24-bit)

 

I just covered the topic once again here:

 

[Miska]

7 minutes ago, KenMoreira said:

Tim Connor (Kitsunehifi) Jul 13, 2021, 7:10 PM PDT Spring3 and May are both 24bit dacs. Effective resolution is more like 22 bit for spring3 and 23bit for May. Far better than most chip dacs that are 32bit etc and few of those surpass 20bit effective resolution

 

Here is for example Stereophile's linearity measurement of May:

You can see it begins to go off at -120 dB which equals to 20 bit.

 

But using 20 or less bits correctly, you can take it way beyond that point.

 

[Miska]

1 minute ago, GoldenOne said:

Fwiw I got much better results when linearity testing my may (and the spring 3) in nos

 

Will post here in the morning

 

Likely depends on the particular unit as well due to manufacturing tolerances. But since 20 bits can give over 160 dB digital dynamic range over 100 kHz bandwidth, it is safe to use it, or even much less bits and still be sure that the noise floor is dominated by analog noise.

 

On my testing of Spring 2 I could drop number of output bits to 16 and still noise floor was dominated by the analog noise, and thus wasn't limited by number of bits used.

 

Once I get my Spring 3 I will run measurements for it too the same way I've done for other DACs.

 

But I'd say it is safest to use at most 20 bits, since there's no reason to use more and it is around the figure there is most consensus about in measurements.

 

[Miska]

9 hours ago, KenMoreira said:

Does all this mean I should be limiting my playback to 24bit in tidal / audirvana?  Or just to 20bit in hqplayer only? 

 

Tidal is 24-bit at most anyway.

 

You can improve performance over standard 24-bit output by using suitable upsampling and noise shaping with output bits limited to 20.

 

 

[Miska]

5 hours ago, CJH said:

Miska

Which version of the Spring 3 are you getting?

 

L2 just as Spring 1 and 2 before.