Massively improve the SQ of computer audio streaming?

[Miska]

12 minutes ago, Superdad said:

1>I2S>Holo Spring L3 (set to NOS).  So two questions:

1) Short buffer or long buffer recommended?  Or something in the middle;

 

For ASIO drivers usually and Thesycon ASIO driver, like in above case and in Spring case, leave HQPlayer "Buffer time" setting at "Default" meaning it'll use what ever driver proposes. In driver's control panel then select the buffer size. I use safest mode and biggest buffer the driver supports (which is not very big to begin with)...

 

When you are using 352.8k PCM, from USB driver and interface point of view it is same as using native DSD256. So given buffer size X it is twice longer in time compared to same size at DSD512.

 

12 minutes ago, Superdad said:

2) If I turn off filters and dither entirely (yes, for NOS artifacts and all), does your DAC bits setting still have any effect?  Are there other HQP settings still doing some DSP when PCM filters & dither are off?

 

Yes, because it defines how many non-zero bits are being sent to the DAC. If dither is off, it defines at what bit depth the samples are rounded at. Volume control and such are always active. If you are careful with the settings you can get bit-perfect output though. But that has of course never been any kind of focus area. (you can also get "bit-perfect" upsampling too where every Nth output sample value matches original)

 

[Miska]

For example you can set DAC Bits to 8 and compare how different dither settings sound in an emphasized way.

 

Of course for DSD output it doesn't have any effect...

[Superdad]

2 minutes ago, Miska said:

For ASIO drivers usually and Thesycon ASIO driver...

 

Thanks, and I have read that from you before.  But as mentioned, I am running HQP Desktop on macOS, so there are no accessible driver adjustments.  

 

Which reminds me: Since I am sending to NAA and not using CoreAudio/UAC2, are not the buffers in the NAA?  Since for NAA it is the endpoint where the DAC or DDC drivers reside.

I admit this stuff confuses me sometimes. 

 

2 minutes ago, Miska said:

If you are careful with the settings you can get bit-perfect output though. But that has of course never been any kind of focus area.

 

Thanks for the clarification about the DAC Bits setting.  It would be helpful to know from you which other settings affect “bit perfectness.” 

[Superdad]

5 minutes ago, Miska said:

For example you can set DAC Bits to 8 and compare how different dither settings sound in an emphasized way.

 

I am sure I have told you in the past (and emphasized to other HQP users) how critical I find DAC Bits setting to be—and how much getting it right dramatically increases effectiveness of your dither settings. 

Since you now also have a Holo Spring, what DAC Bits setting do you find best for it?

Mine is fed via I2S from a Singxer SU-1–which I am sure reports itself to the computer as 32-bit capable.  Hence the need for sure to dial that down (in HQP) for the Spring.

Thamks again.

[Miska]

12 minutes ago, Superdad said:

Thanks for the clarification about the DAC Bits setting.  It would be helpful to know from you which other settings affect “bit perfectness.” 

 

Pretty much everything...

 

But if you turned off everything, set filter and dither to none and volume to 0 dBFS you are likely getting bit perfect output. Some DACs have tests for this, like RME, where you play special file and DAC will display results of the bit test.

 

12 minutes ago, Superdad said:

Thanks, and I have read that from you before.  But as mentioned, I am running HQP Desktop on macOS, so there are no accessible driver adjustments.

 

Yes, that's the case when output is CoreAudio.

 

12 minutes ago, Superdad said:

Which reminds me: Since I am sending to NAA and not using CoreAudio/UAC2, are not the buffers in the NAA?  Since for NAA it is the endpoint where the DAC or DDC drivers reside.

 

Thats right. If the NAA is running Linux, then you can adjust buffers from HQPlayer. But I'd recommend leaving it at "Default" which is 100ms. If NAA is for example Windows computer and using ASIO backend, then earlier statement about ASIO buffer settings still apply. If NAA is Mac with CoreAudio, you cannot adjust buffer sizes.

 

And note that some ASIO drivers just don't have any kind of buffer size adjustment, like the ones sourced from Amanero.

 

[beerandmusic]

8 hours ago, Superdad said:

 

You are still in denial after all these years Dennis?  The differences people report—and which I plainly hear every day in my system—are far from random.

It does take a bit of training and comparison to tune your ear/brain into the type of sonic difference signal integrity improvements make.  Rather similar (though often more dramatic than) the variations heard between different digital filters.

Oh wait, I seem to recall reading you say you don’t hear differences between digital filters either.  Sorry...

 

So are you on the bandwagon amongst the vast majority that believe that dacs get their the music with 100% accuracy?  And if so, and there are clearly notable SQ differences, then it is just a difference of noise then?  Basically we are paying big bucks for who has the "better noise" and that is the entire difference (up to the dac)?  After all, all that is being transferred to the DAC is the music with noise and voltage with noise??

 

and if so, this continues to baffles me...is engineering so stupid after all these years that they can't get it "right" or at least within 5% of the cheapest to most expensive solutions (at least up to the dac).

[beerandmusic]

8 hours ago, Superdad said:

I think people respond differently to some changes—and some choose what I would consider the worse and less accurate choice

 

 

This i agree 100% with and have thought it a LOT.  i think a lot of people that report OMG improvements are actually liking something less accurate....this has to be true, because so many people report OMG improvements, and you can really have only so many OMG improvements.  This is another reason I am a lot more OBJECTIVE than SUBJECTIVE, and not willing to pay for "subjective" improvements...they likely are not even more accurate.

[beerandmusic]

8 hours ago, Miska said:

 

I'm personally using 100 ms buffers and that is certainly good compromise. That keeps buffer rate at 10 Hz which is below audible frequencies. When you push it to 1 ms you also push the buffer rate to 1 kHz which is within audible frequencies, and in addition increase overhead and produce more noise. USB has 8 kHz packet rate (packet size depends on sample rate), and that frequently shows up in measurements leaking to analog output of the DAC...

 

I never noticed any difference to those stated qualities by changing buffer size.

 

For that same control panel, I set USB Streaming Mode to safest setting and ASIO Buffer to largest setting. Gives best reliability (least likely to have drop outs) and least computer activity.

 

+1

worth noting for all hqplayer enthusiasts.

[beerandmusic]

14 hours ago, jabbr said:

 

I find video to be very stressful on a computer and my first experience with really bad noise was when I was running 4K editing (a few years ago). Smooth, nonstuttering playback requires substantial resources and highlights what a cheap 4K blu-ray player can achieve. Working with video and having noisy and high powered graphics cards does impact SQ in my experience.

 

My solution is to use Ethernet to isolate the noisy PC from the DAC using a very low powered NAA running Linux without a GUI etc. Even with a really low powered Celeron or ARM device, the NAA hardly uses CPU.

 

Low power, low noise, sounds great!

 

This sounds logical to me.  I know HQPlayer has NAA, is that what you are referring to that you use?  That is one of the options that audio-linux offers.....I really don't know much about NAA, but it does sound like a good way to go.  would you need more than one computer in that configuration as the host?  e.g. can i have just one audio-linux pc running naa and point to local hd, and then have a separate pc (or smartphone) to control it, or would you need another pc or nas for the music files?  I am willing to go this route if just one pc (besides the controller).

[jabbr]

28 minutes ago, beerandmusic said:

 

This sounds logical to me.  I know HQPlayer has NAA, is that what you are referring to that you use?  That is one of the options that audio-linux offers.....I really don't know much about NAA, but it does sound like a good way to go.  would you need more than one computer in that configuration as the host?  e.g. can i have just one audio-linux pc running naa and point to local hd, and then have a separate pc (or smartphone) to control it, or would you need another pc or nas for the music files?  I am willing to go this route if just one pc (besides the controller).

 

What I do:

 

1) music and all other media on a central networked NAS.

2) Workstation PC (or embedded server) with GTX1080 runs HQPlayer (and Roon) -- needs to be beefy to upsample to DSD512 etc.

3) several linux NAA boxes, either hardwired or wireless, connected to several DACs by USB. The NAA boxes aren't expensive -- I've described a number of mine including the ClearFog, Espressobin, Celeron J1900, NUCs, RaPis etc.

 

I use my iPhone to control Roon. Alternatively you could use an iPad with web interface to control HQPe. 

[lmitche]

Let's expand on a framework that Jussi discussed somewhere else, the extreme case of DSD512. This is 22,579,920 bits per second. Now let's assume that we have a 1 core 4ghz processor that never waits for data so 4 billion instruction can execute a second. 

 

Dividing 4 Ghz by 22mbps is 181. This means that there are only 181 instructions that can be executed per bit in a dsd512 stream on our fictional 1 core processor. OK, so we have four cores, now we are at 724 instructions per bit. That's a very low budget for a realtime process especially one that is doing bitwise operations.

 

In this context, the impact the processor doing anything unrelated to audio, like the Windows OS that constantly plays with itself, one can quickly see that things can get stretched or delayed waiting for a processor.

 

Understanding this also tell us that what Jussi does in Hqplayer is a modern miracle. It also may explain why AL has such a great impact.

 

And yes, I know, the real world is much more complicated with lower resolution than dsd512, DMA, caches, efficient compilers, instruction look-ahead and execution . . . blah, blah, blah. 

 

Larry

[beerandmusic]

3 hours ago, jabbr said:

 

What I do:

 

1) music and all other media on a central networked NAS.

2) Workstation PC (or embedded server) with GTX1080 runs HQPlayer (and Roon) -- needs to be beefy to upsample to DSD512 etc.

3) several linux NAA boxes, either hardwired or wireless, connected to several DACs by USB. The NAA boxes aren't expensive -- I've described a number of mine including the ClearFog, Espressobin, Celeron J1900, NUCs, RaPis etc.

 

I use my iPhone to control Roon. Alternatively you could use an iPad with web interface to control HQPe. 

thanks.

 

1. why several naa boxes and several dacs instead of just naa box and one dac?

2. my  main question is can the music be on the same box as the naa? 

 

i reallly only want a 2 box solution (player and host or whatever you want to call it)..i suppose i could buy a nas later, but i really just want a 2 box solution.

 

edit: i guess black friday is here, i guess i can pick up a nas cheap these days....which do you recommend on the cheap?

 

i really have been staying away from nas as i am not sure what value they add over just a network share since i have many computers and ssd drives here already if i am not concerned with raid. (i use ssd exclusively and have an automatic backup system already).

[beerandmusic]

1 hour ago, lmitche said:

Let's expand on a framework that Jussi discussed somewhere else, the extreme case of DSD512. This is 22,579,920 bits per second. Now let's assume that we have a 1 core 4ghz processor that never waits for data so 4 billion instruction can execute a second. 

 

Dividing 4 Ghz by 22mbps is 181. This means that there are only 181 instructions that can be executed per bit in a dsd512 stream on our fictional 1 core processor. OK, so we have four cores, now we are at 724 instructions per bit. That's a very low budget for a realtime process especially one that is doing bitwise operations.

 

In this context, the impact the processor doing anything unrelated to audio, like the Windows OS that constantly plays with itself, one can quickly see that things can get stretched or delayed waiting for a processor.

 

Understanding this also tell us that what Jussi does in Hqplayer is a modern miracle. It also may explain why AL has such a great impact.

 

And yes, I know, the real world is much more complicated with lower resolution than dsd512, DMA, caches, efficient compilers, instruction look-ahead and execution . . . blah, blah, blah. 

 

Larry

 

Can you explain why if the bits get to the dac with 100% accuracy like everyone agrees, why any of this stuff matters?  I am not doubting, i just am looking for logical reasoning as to why?  This stuff sounds like it would affect timing and data accuracy,, but not sure how it would affect noise?

[lmitche]

Just now, beerandmusic said:

 

Can you explain why if the bits get to the dac with 100% accuracy like everyone agrees, why any of this stuff matters?  I am not doubting, i just am looking for logical reasoning as to why?

Nope, unless they arrive too late.

[beerandmusic]

9 minutes ago, lmitche said:

Nope, unless they arrive too late.

arriving late would affect data or noise?  everyone agrees that the dac gets the data with 100% accuracy, so arriving late affects "noise"? 

 

I am curious why everyone thinks that the dac gets the data with 100% accuracy (at the right time)?  is there any way to really determine that the dac gets the data with 100% accuracy at the "right time"?  I mean its at very high resolution and very fast....And if that is really the case, then the only thing it can be is "noise"?

 

Also, if dacs get their data with 100% accuracy at the right time, then why do low phase clocks even matter?

 

It seems to me that a solution should be perfected (at digital end, prior to analog out) easily if you had a dac engineer that designed both the digital in system including clocking/timing and the dac, rather than 2 different engineers trying to piece it together.  But it will take a pretty good dac engineer (smile).

 

I wonder if the front of a streamer dac (e.g. altair with lps, ultra low noise clocks and dac), if the digital front end is
"as good as" these other linux streamers?

 

[mansr]

6 minutes ago, beerandmusic said:

arriving late would affect data or noise?  everyone agrees that the dac gets the data with 100% accuracy, so arriving late affects "noise"? 

Late arriving data results in dropouts or pops/clicks.

 

[beerandmusic]

13 minutes ago, mansr said:

Late arriving data results in dropouts or pops/clicks.

 

Yes, i have heard that before, but I am not sure I am 100% convinced of that.  I believe it will cause that, but is it also possible that if the data is 100% accurate, but dac doesn't process at right time that it could cause something besides a dropout?  I mean if you have a million bits at t1 and the dac gets a million bits minus one bit at t1, and the millionth bit is carried over to t2 along with another 1 million bits, would you really hear a dropout?  Of course these are hypothetical numbers, but just saying.  I have to think that some of those bits are for harmonies where the loss of 1 bit may make the harmonic sound slightly different, but not a dropout.

 

Anyway, that is my thinking, and probably everyone and their mother will disagree with me, but i don't think anyone can convince me otherwise..i am pretty stubborn and ignorant with my logic if i can't see it plainly (grin).

 

I just find it very difficult to believe that we are just paying for who has better "noise", if the data is always 100% accurate gettting to the dac at the right  time.  Plus that no one can identify which "noise" is more accurate...yet there are so many "omg" moments.

[beerandmusic]

^^^more thoughts to myself....

 

If Miska could answer above, i am sure he would sound logical, and I may be able to accept it, that if even one bit of a million bits arrives late, it will always result in a dropout that could easily be heard, ....provided he could also explain why so many people report OMG improvements based just on noise, not the data (since the dac reportedly receives the data with 100% accuracy and the only other thing being transferred is noise), and that is why people report omg differences that this "noise" can't be managed at least to an audible level, that this noise can cause dramatic depth, soundstage, detail, bass, etc... differences that cannot be managed effectively.

[beerandmusic]

^^^^ I think i answered my own question...and i was half right (ok, call it 1% right-grin)....

 

the timing is IMPORTANT because the noise (jitter), does cause "harmonic distortion".  I knew the SQ concernt would be more along harmonics than dropouts, but I guess i must admit, it is more about jitter than accuracy.

 

++++++++++

https://www.design-reuse.com/articles/5763/timing-key-to-optimizing-audio-performance-in-consumer-products.html

 

most notably: As little as 1 to 2 nanoseconds of clock jitter can cause a large degradation in the system's ability to play back a wide range of audio content (dynamic range) and an increase o f harmonic distortion

++++++++++

 

So it really is about timing, probably more than anything...more than power (not to say it doesn't matter)...but when we are dealing with such high speed processing, we need to control the jitter.  I am not convinced that any front end with good clocks (coordination between dac and source), that does not have "unnecessary interrupts", should be very cheap and easy to do.

 

This probably answers why usb toys works too, because of pc's (most common method of usb dac in "passed").  THis is why i always preferred enet to usb even before usb toys, likely because of non-dedicated pc doing processing).  USB toys and even enet probably is not necessary, provided a front end with good clocks without unnecessary interrupts... i also am not sure reading from a local ssd would cause any more unnecessary interrupts than streaming from enet.

 

[fas42]

As regards hearing differences, once one has learned to be sensitive to what's going on even very ordinary gear makes it apparent that optimisation is worthwhile. I have an old, ordinary HP laptop, just using its internal speakers - and at one stage decided to aim for the best SQ for CDs playing on CD-ROM drive. Software like Foobar were rejected very quickly, and ended up with Media Monkey whicha allowed a lot of fine tuning with buffering, etc; it turned out that there was a very precise set of parameters settings which were "just right" - moving one notch either side of this "best fit" in any area lost quality - going back and trying something like Foobar again was truly awful, the losses were unacceptable.

[beerandmusic]

^^^^ the fact that nano-seconds of jitter can cause dramatic differences to dynamic range and harmonic distortion, does show the importance of timing, but IMHO, with engineering what it is today (maybe not in audio world, but computer world), we should be at a point at this day and time to have this stuff nailed down.  I am unimpressed with audio engineers, that they cannot get this done cheaply a LONG time ago (i mean litterally decades ago).  this should not be rocket science, even if we are talking nano-seconds.   With today's computer power, clock circuitry, this should be rudimentary at best....and perhaps it already has been perfected cheaply (to an audible level), just marketing, sales, and ignorance, continues to work on the ignorant. 

 

Now that i have come to this realization, it is probably time to invest in a cheap front end and cheap dac and be done with all this non-sense....i am not even sure that "BIG BOX solutions" are not already there, but marketing, reviews, ignorance, and survivability of boutique audio shops, have refused to let it mature...at least for the front end.  I am flabbergasted that it has taken to 2018 to realize what we know today.

 

I think part of the reason, i dismissed "noise/jitter" as the sole reason for digital SQ, is because i have heard before that noise/jitter sounds like hiss (not that it can cause other issues as well, such as harmonic distortion).  So i will forget all those posts that say jitter sounds like hiss, or listen to this wav to hear what jitter sounds like)...jitter is a bigger animal than hiss.

[fas42]

Chasing one 'magical' factor as being the cause for the SQ not being up to scratch - like timing "not quite right" - is very much painting yourself into a corner, in my book. My approach is to see a system, any system, as being riddled with problems, and one has to work through each issue, one after the other - like the tortoise, - hare brained chasing of the Big One as the Answer To Everything is something I would never do.

[beerandmusic]

11 minutes ago, fas42 said:

Chasing one 'magical' factor as being the cause for the SQ not being up to scratch - like timing "not quite right" - is very much painting yourself into a corner, in my book. My approach is to see a system, any system, as being riddled with problems, and one has to work through each issue, one after the other - like the tortoise, - hare brained chasing of the Big One as the Answer To Everything is something I would never do.

 

I am not arguing that point...i am talking only about the digital front end (getting the digital, and jitter perfected to the dac to an "audible" level....of course never perfect)...i am not talking dac, speakers, room, dsp, etc....only the front end to the dac....this should be able to be perfected to an audible level and CHEAPLY long ago....but i am a ones and zero's type of guy, so i just have higher expectations for the "digital engineers", granted digital audio is it's own beast beyond data...but still....

[fas42]

What's not 'perfected' is 'perfectly' isolating the following analogue circuitry, fom DAC onwards, to digital circuitry behaving any way it likes while still maintaining 100% data integrity; when monitored using analogue instrumentation.

[LTG2010]

13 minutes ago, beerandmusic said:

I am not arguing that point...i am talking only about the front end (getting the digital, and jitter perfected to the dac)...i am not talking dac, speakers, room, dsp, etc....only the front end to the dac....this should be able to be perfected to an audible level and CHEAPLY long ago.

Many engineers believe the DAC's buffers can deal with Jitter and the only important clock is that in the DAC itself. It's not generally accepted that small amounts of Jitter can affect sound quality, let alone any concept of software induced jitter, It's a more recent thing, better clocks, etc. in servers.