HOLO Audio MAY DAC

[Extreme_Boky]

Asynchronous USB looks to be the perfect solution; you configure your PC for bit-perfect output and the DAC takes care of the timing totally independent of the timing of the PC.

 

But there are posts on the Internet claiming that even in the case of an async USB DAC what is happening upstream is still affecting sound quality. Sending a signal to a DAC is done using a 100% analogue waveform/carier. The digital packets are superimposed on this, still analogue, waveform. 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 is theoretically meant to make the USB receiving device immune to the PC, but..... it isn't immune. I can clearly hear the difference in sound when I use various laptops/desktops/NUC11.  I found the lower the switching frequency of the CPU and the lower the switching voltage of the CPU (the switching voltages in general... on the motherboard) - the more pleasing and analogue sound I hear.

[lpost]

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.

[GoldenOne]

I measured the jitter from the may fed by USB and it did not change at all when PLL was on vs off.
Other inputs did of course, but USB did not. (It was excellent in both situations though, with firmware on 3014 (was using 3012 previously which didn't seem to play nice with my AMD pc, i'm getting much better results on USB now, not that they were bad before, also I have a new ADC so can measure much lower)

 I got jitter close sidebands at -155dB and wideband random jitter approaching -170dB. Insane

 

[barrows]

10 minutes 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.

No, any processor chip requires its own clock to operate.  So, for example, a USB hub chip (which is always present at each end of a USB communication run) requires a specific clock frequency of its own to operate.  This USB clock has nothing to do with the audio clock(s) which are used to clock the audio data stream out of the USB receiver and into the DAC's conversion stage.  The audio clocks are what is relevant to the "jitter" of audio data stream and any subsequent sound quality issues there.

But, the performance of the USB clock has been demonstrated to have an effect on sound quality as well, at this point, no one I am aware of has really figured out why the USB clock's performance on phase noise seems to matter for sound quality, but the anecdotal evidence of such has shown this influence to be clearly audible.  So, while the USB clock does not have a direct effect on audio jitter levels, it does appear to have some effect regarding sound quality.

[Diavolo]

10 hours ago, Miska said:

 

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.

 

 

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

 

 

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

 

My benchmark usb wasn't 1.0. You're mistaken and now I'm quite sorry I bought your fraud-ware.  Go read a white paper on their site.  

 

Kneel before lord Miska... Nope 😁 

[lpost]

13 minutes ago, Diavolo said:

Kneel before lord Miska... Nope 😁 

Harsh dude. Clearly there is some history between you and Jussi but it's probably not appropriate to spread on public forums.

 

He's been most helpful and patient/tolerant with me over the years.

[Diavolo]

1 minute ago, lpost said:

Harsh dude. Clearly there is some history between you and Jussi but it's probably not appropriate to spread on public forums.

 

He's been most helpful and patient/tolerant with me over the years.

No history whatsoever. Not interested either.  He can drink his kool-aid, I prefer the purple stuff.  

[lpost]

Fair enough. What does your audio path look like?

[Diavolo]

Just now, lpost said:

Fair enough. What does your audio path look like?

Pristine, and I'm not interested in a debate with you. 

[lpost]

I'm curious, not looking to debate. I'm here to learn, not argue, ever.

 

I use Roon Core on a Windows box to HQPe on a PC to NAA on my endpoint AMD machine and then USB to May. I've tried running Roon Bridge on endpoint and didn't care for the sound compared to HQPe in the path whether upsampled or not. And I'm open to any other config that brings me closer to nirvana and/or less fuss without compromising the SQ.

[Diavolo]

3 minutes ago, lpost said:

I'm curious, not looking to debate. I'm here to learn, not argue, ever.

 

I use Roon Core on a Windows box to HQPe on a PC to NAA on my endpoint AMD machine and then USB to May. I've tried running Roon Bridge on endpoint and didn't care for the sound compared to HQPe in the path whether upsampled or not. And I'm open to any other config that brings me closer to nirvana and/or less fuss without compromising the SQ.

To each their own.  After months of comparison, hqplay-ed is not in my system.  I send everything pcm native to my May over usb from roon directly at native sample rates. Sounds the best and is the simplest path. 

 

I'm not alone in this assessment either. 

[ted_b]

19 minutes ago, Diavolo said:

Pristine, and I'm not interested in a debate with you. 

Then don't respond!!!  Don't be a dick about it.  Your opinions are often valuable, but folks will begin to devalue them with these kinds of responses.  This is a good forum; let's keep it civil.

[Diavolo]

3 minutes ago, ted_b said:

Then don't respond!!!  Don't be a dick about it.  Your opinions are often valuable, but folks will begin to devalue them with these kinds of responses.  This is a good forum; let's keep it civil.

Being a dick?  By simply not wishing to respond and stating it.  Really?  Jeez. 

 

Hqplayer secretly is mining BTC in the background with the EC modulators enabled is my guess.  🤣

 

Now I'm being a dick. 

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

 

[Mops911]

4 hours ago, Diavolo said:

Kneel before lord Miska... Nope 😁 

From uncivil newbie to uncivil newbie ;-)

 

It took me 8min to read up on PLL, Benchmark and async USB, and its complete nonsense you wrote about it.

 

Also, the white papers from benchmark are null haha

https://benchmarkmedia.com/blogs/white-papers

 

ok, I stop here for civility sake....

 

but let me quote from benchmark

https://benchmarkmedia.com/blogs/application_notes/inside-the-dac2-part-2-digital-processing

The DAC2 USB interface uses the asynchronous data transfer mode to pull audio data from the computer. A clock generated inside the DAC2 is used to transfer the data. The asynchronous mode eliminates the need to recover a conversion clock from a potentially noisy computer-generated clock. For this reason, the asynchronous transfer mode produces almost no jitter, and any jitter that is produced by the USB subsystem is fully-removed by the UltraLock2 jitter attenuation system.

 

[Diavolo]

Civility? More lik

9 minutes ago, Mops911 said:

From uncivil newbie to uncivil newbie ;-)

 

It took me 8min to read up on PLL, Benchmark and async USB, and its complete nonsense you wrote about it.

 

Also, the white papers from benchmark are null haha

https://benchmarkmedia.com/blogs/white-papers

 

ok, I stop here for civility sake....

 

but let me quote from benchmark

https://benchmarkmedia.com/blogs/application_notes/inside-the-dac2-part-2-digital-processing

The DAC2 USB interface uses the asynchronous data transfer mode to pull audio data from the computer. A clock generated inside the DAC2 is used to transfer the data. The asynchronous mode eliminates the need to recover a conversion clock from a potentially noisy computer-generated clock. For this reason, the asynchronous transfer mode produces almost no jitter, and any jitter that is produced by the USB subsystem is fully-removed by the UltraLock2 jitter attenuation system.

 

Yup, that's what it says. Not sure what point you're making.  Thanks for posting the white paper? I guess we all needed you to save us captain save a ho. As far civility you have none. You're just a suck up. 

[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

 

[Diavolo]

43 minutes ago, Miska said:

 

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.

 

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

[Diavolo]

Just now, Miska said:

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

 

Yawnnnnn. Couldn't tell in my system, I guess if I invest $50k more I'll hear a difference. 

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

 

[Diavolo]

1 minute ago, Miska said:

 

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

 

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. 

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

 

[Diavolo]

1 minute ago, Miska said:

 

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.

 

It doesn't improve sound quality. 

I used it for months just so I could be fair to it, but It's a big fat Nothing Burger 🍔.  I wish I could hear some improvement, but there just wasn't. Sorry, it's snake oil to me. That's just my opinion. By all means let your minions continue bringing you victims to brainwash into thinking they heard something. I'm just not one of them. 

 

Have a good day. Hope you have a banner year. 

 

Its just an opinion, relax. 

 

[ted_b]

I’m a long time HQPlayer user. It is the best upsampling engine I’ve ever heard. Your loss if you don’t hear the improvements. But calling us victims and minions, belittling the developer....this is not within your right. As I said earlier, this forum rises above your childish level of responses. Get over yourself.