HQPlayer Linux Desktop and HQplayer embedded

[barrows]

Hey folks, I am finally trying to get going with HQPe.  My Bricasti M3 DAC sounds fantastic via its discrete DSD converter, just via Roon oversampling to DSD 256, but I have auditioned HQP a couple of times previously, and know that DSD 256 with ASDMEC7 is heavenly.  Given the reduction in price of the i9-9900K I had a simple server built using it, with 16 Gb of RAM (2400 MHz, CL17) and a active fan radiator on the processor.  My research indicated this set up should run Roon + HQPe, with ASDM7EC and the poly-sinc ext2 filter to DSD 256.

 

I have success with the ASDMEC5, but with ASDMEC7 I get dropouts every few seconds.  Settings below, am I missing something?  I do not think i should need a CUDA offload for poly-sinc ext2?

 

 

[barrows]

1 minute ago, ASRMichael said:

Try setting buffer to 100ms. 

I'll give it a go.  Note that I am using NAA if that makes a difference.

[barrows]

Changing the buffer from "0" to "100" made no difference, still dropouts every few seconds with ASDMEC7 poly-sinc ext2 to DSD 256.

This is maddening here.

[barrows]

7 hours ago, Miska said:

 

Which Linux distribution and HQPlayer build are you using? Do you get the same also with simpler ASDM7 modulator?

 

If you get the same also with ASDM7 then it is a network problem. Any smart switches in the network? If yes, then please check that you have 802.3x Flow Control enabled. Without functional 802.3x you'll get what you describe with Rendu on a gigabit network because it is not able to handle sustained 1 Gbps transfers without packet loss (it can do max 400 Mbps and that only with functional 802.3x).

 

ASDM7 and poly-sinc ext2 to DSD 256 with any base rate works perfectly, ASDMEC5 and poly-sinc ext2 works perfectly, only ASDMEC7 has dropouts.  OS is Andrew's (Small Green Computer) linux variant.  HQPe is latest version.

 

I will check my switch for flow control right now.  Looks like flow control was disabled, I will now test with it enabled, fingers crossed!  Thanks Jussi!

[barrows]

8 hours ago, Miska said:

 

Which Linux distribution and HQPlayer build are you using? Do you get the same also with simpler ASDM7 modulator?

 

If you get the same also with ASDM7 then it is a network problem. Any smart switches in the network? If yes, then please check that you have 802.3x Flow Control enabled. Without functional 802.3x you'll get what you describe with Rendu on a gigabit network because it is not able to handle sustained 1 Gbps transfers without packet loss (it can do max 400 Mbps and that only with functional 802.3x).

 

As DSD 256 works perfectly well with ASDM7 or ASDMEC5, I do not see how anything on the Network could be affecting performance with a different modulator, right?  I suspect the problem is something with the server and not Network related as DSD 256 plays perfectly (and 512 as well) with lower load modulators.  Am I right to conclude that the server must be the issue given this situation?

 

Enabling flow control in the switch made no difference to the results.

[barrows]

3 hours ago, luisma said:

Thanks this means HQPe will never play above Nyquist either, 22.05 is the max frequency, meaning ultrasonics are always discarded correct?

 

Of course there is nothing there that was there originally, just ultrasonics residual from the noise shaper

Only with source files of 44.1 content.  This is not different than any other oversampling approach.  You cannot "create" ultrasonic content which was not captured by the original recording.  Nothing is "discarded".

[barrows]

1 hour ago, lpost said:

I just had the white noise occur with HQPe machine directly connected, no NAA. NAA doesn't appear to be the culprit. I think I'll go back to 4.22.3 and wait for the next version.

IME, white noise events such as this are usually the result of a problem with the DAC losing lock, or not achieving lock at startup of the signal.  Of course, the digital signal from the source may have an influence over this problem as well in terms of how it starts up the signal.  The DAC has a limited amount of time to achieve lock before it unmutes its output, and sometimes, some DACs, seem to not be able to establish a lock, and then one gets the blast of white noise.  This may be due to the USB interface in the May, or it may be due to the rechecking stage/PLL after the USB interface.  Does the issue occur under both PLL-on and PLL-off settings?  A relatively narrow PLL, such as is used in the May might be the cause.  I do not have a May here, so cannot test these ideas, but I do know that it can be very tricky for DAC designers to get things set up just right, such that the DAC will always lock, with every source, before unmuting its output.

[barrows]

@Miska, @agillis:

 

HQPe/sonic transporter new v. 28.2 w Roon, playback is stopping requiring a restart to resume.  Sometimes it just pauses and clicking the play button will resume play, but other times it needs a total restart.

[barrows]

21 hours ago, barrows said:

@Miska, @agillis:

 

HQPe/sonic transporter new v. 28.2 w Roon, playback is stopping requiring a restart to resume.  Sometimes it just pauses and clicking the play button will resume play, but other times it needs a total restart.

@Miska, @agillis:  Still having the same issues now with 4.28.3.  Playback stalls and requires re-boot(s) to run again.  I have had to revert to using Roon alone to listen to music now, it does not sound nearly as good as HQPe...

[barrows]

5 minutes ago, Mike Rubin said:

This might be a stupid question, but that’s never stopped me before.

 

I am running HQPlayer Embedded OS on a NUC 10i7, but have had similar issues when using HQPlayer Desktop.  With the latest iterations, I can get all of ASDM5ECv2, ASDM7ECv2, and DSD5v2 256+fs modulators to work pretty reliably with the poly-sinc-gauss-long filters.  I upsample everything to DSD256.  Usually, but not always, I use JRiver as a front end (controlled by JRemote on an Android phone),but I often use HQPD Control v4instead.

 

I can listen for pretty extended periods of time, but, randomly, will start having dropouts that last from a second or two to at least five seconds.  Infrequently, the music just stops altogether.  I have noticed this problem more with mp3 files but that might be a coincidence because it also happens even with hi-res files.  It can happen even if there is no other network traffic of significance .
 

Obviously, something isn’t quite right, but I have no idea how to troubleshoot this. My question is: At what should I be looking if I want to troubleshoot?  Am I asking too much of the NUC cpu with these modulators, am I running into heat-related NUC throttling, is there an issue with my network that manifests even if there isn’t much traffic, is my using my phone while listening causing a bottleneck, is my AfterDark clock/EtherRegen combination causing the stream to get out of whack, or is there something else to check?  
 

I will appreciate suggestions.

Usually, If your computer does not have enough power to run a given HQPlayer setup, you will get relatively consistent stuttering, or consistent dropouts every few seconds, rather than occasional dropouts.  Occasional dropouts sound like a Network related issue to me.  First test this theory by playing at the same output data rate (DSD 256) but with an easier computer load: try running with the ASDM5 (non EC) modulator, and a relatively low load filter, but still with DSD 256 output rate, you can make it a little easier by choosing a 44.1 file rate as well.

Consider that the output rate is what matters as far as the Network is considered.  If you still have the same occasional dropouts, it is safe to assume that the problem is Network related.  Are you running from A to B side on the EtherRegen?  if so, note that this limiting your throughput speed to 100 Mb, and Jussi recommends using gear which keeps a 1Gb speed throughput, so that might be a limitation.  Also consider little things which one at first might not think about: like make sure whatever power supply you are using on the EtherRegen has plenty of current capability to run it well, do not use a power supply that is running close to its limits for the load.  Try testing if the EtherRegen is a source of your problem by replacing it with a simple consumer FMC which is 1Gb in speed (these are cheap and easy to have around).

[barrows]

20 minutes ago, Mike Rubin said:

Just double checked. Etheregen sfp connection is 1gb only, so my entire signal chain is 1gb. 

Incorrect, if you go from the A side, to the B side on the Etheregen, you are limited to 100 Mb speed. I believe this limitation is due to the limited speed of the isolators used in the Er.  The forthcoming Er2 will have full Gbe support on both sides.

[barrows]

21 minutes ago, Mike Rubin said:

If that were true, would the rendu would work at all?  It requires a 1gb signal, I thought.

 

No, it will work with a 100 Mb signal, which is what you have.  In fact, DSD 256 will pass with only a 100 Mb signal, usually without problems (I have tested here, with my switch I can set the rate to 100 Mb if I want).  But Jussi recommends that for best reliability and performance that one maintain Gb connection speeds for best performance with NAA.  Here I run DSD 256 all the time, and make sure everything runs at Gb speeds (except for the testing mentioned).

In any case, first test the NUC by running for a few days with the lower load modulators, ASDM5 (non EC) and see if you have no problems.  If you have no problems, then you know the NUC is the bottleneck if you want to use the EC modulators (I find EC modulators to be a big improvement here).  If you do still have problems, then start testing the Network stuff.

I use the Sonore opticalModuledeluxe v.2 here to provide fiber to my Signature, and it runs at Gb speeds (but does not offer the same level of isolation as the Er).

[barrows]

2 hours ago, Tihon said:

@stefano_mbp Thank you! Looks like the custom server path is not for me.

Tihon, if you are interested in running HQPlayer for its oversampling capabilities, but you are unsure of being adept enough with computers to do so, you might consider a simpler solution:  Small Green Computer builds the Sonic Transporter line of music servers.  These can be purchased with HQPlayer embedded and Roon already onboard and mostly configured.  While they are the most powerful servers out there, their top model does have enough power to run most oversampling configurations with HQPlayer.  The Sonic Transporters run their own OS, and includes a web based GUI for controlling software updates and making settings in HQPlayer-these are quite simple to use and configure.  The customer support from Small Green Computer is also quite good.

[barrows]

11 minutes ago, Tihon said:

@barrows thank you. That’s not my case, unfortunately. I’m interested in more powerful config to run DSD512-1024 upsampling with EC modulators.

With the latest version of HQPlayer (5), you may be able to get to DSD 512 with EC modulators with the top build of the Sonic Transporter.  Probably not 1024 though...  I would suggest you contact Andrew at Small Green Computer and consult with him.  Alternatively, his company might be willing to build something custom for you, using the Sonic Orbiter OS with HQP and Roon-it is worth asking if you want to get into HQPlayer but do not have the computer savvy to set it up yourself.

[barrows]

1 hour ago, quinn_t said:

I am also thinking along the same line.

By the way, Linn has done a very good job at dealing with noisy USB input, at the moment it is the best streamer/DAC that I've come across.

Ummm...  USB inputs are not inherently noisy!  USB is an excellent choice for a DAC input, as long as the USB SOURCE is designed to be low noise (meaning a purpose built streamer/renderer designed for high end audio use).  In fact, wired Ethernet sources have a lot of network noise on them.  Just as is the case with USB, an Ethernet input on a DAC needs to be very carefully implemented to not produce noise which gets to the DAC clock circuit and analog circuitry.  I do trust that Linn, being one of the very first network capable DACs has a good Ethernet input design (and likely a good USB input design as well).

This idea that there is something inherently "wrong" with USB for audio is flawed.  A well implemented USB input can perform as well as, or better than, any other DAC input.  This is the same for all DAC inputs-if they are properly implemented, and the source components is also properly implemented, any input format can produce best possible sound quality.  From a technical perspective, an Ethernet input is actually the most difficult to make work really well inside a DAC, because Ethernet processing requires more processing power than any other input type-it can be done, but it needs to be very carefully engineered and isolated/shielded from the rest of the DAC to work well inside a DAC chassis. 

[barrows]

6 minutes ago, quinn_t said:

You really have some good points here. Generally, the Mac Mini or any PC is not a very good USB source.

 

Yeah, it is just like anything-source component quality matters, regardless of input format (SPDIF, USB, etc).  With some DACs, how much difference the source quality matters is different (some less, some more) but every DAC still seems to respond with better performance when paired with a high performing source component.

[barrows]

5 hours ago, Gato said:

With HQPlayerOS, is it a way to check power consumption?

What do you really want to know?  Are you curious of your server's entire power consumption?  If so a simple way to figure this out os to use a watt meter inline with the AC supply from the wall to your server's power supplies.  These meters are easily available from Amazon, etc and are not expensive.