Since installing build 99, I am experiencing dropouts when playing using HQPlayer. These dropouts did not occur before build 99, so I don’t think it’s a performance issue.
I have tried HQPlayer 3.12 and 3.13b2 and get similar results. I am using Roon with an Oppo HA-1 upsampling to DSD128 with poy-sinc and poly-sinc-2s.
Nothing has changed in Build 99 with regard to stream delivery, only track switching.
We allow HQPlayer to buffer as much data as it wants from us, so it should be able to keep enough buffer to prevent dropouts assuming that your machine can handle the filter choices. Roon is really just a pass-through. We’re reading bits from a file and putting them onto a socket to HQPlayer–there’s no expensive work going on in side of Roon where things could really get hung up.
The expensive parts are reading the data from disk/network (which is up to the OS/NAS), the filtering component in HQPlayer, and managing the data transmission to the DAC. Dropouts are almost certain to trace back to one of those three areas.
Maybe there’s an environmental cause? Something else loading your machine, or competing for I/O bandwidth loading the media over disk/network?
It might be a good experiment to try choosing less demanding filters (perhaps, PCM output at 1x), see if the dropouts improve. If they do, then try gradually increasing the filter demand to see when the problem begins to appear. At the very least, we’ll get some insight into what’s going on.
I’ve been having static, dropouts and stutters using Builds 94 and 99 with 3.12 and 3.13 when upsampling and converting from hi-res to DSD256. Works with no problem in HQPlayer alone using polysinc and ASDM7 (except it stutters when converting 44.1 based PCM to 48 based DSD). Makes no difference changing filters. Roon seems to be adding some overhead or HQPlayer is receiving the files in a way that adds overhead.
(Mac Pro 6-core 3.5 / 32gb RAM)
The input mechanism in HQPlayer for receiving content from Roon is new, different from how it loads content from files, and also under active development over there.
I know how Roon works inside–we’re pulling bits from a file and putting them on a socket, that’s it. There’s no additional overhead. HQPlayer decides how quickly to pull data from us, and how much to buffer.
Maybe HQPlayer buffers more deeply when it’s reading files directly than when it’s pulling data from Roon, or something like that. I suggest that you bring this up with them.
Thanks Brian. I’ll check with Jussi.
Today, I played a number of songs in various formats. They all played fine with no dropouts. The only change I’ve made is checking Pipeline SDM in HQPlayer settings.
As you suggested, I believe the cause of the dropouts is in how HQPlayer handles the incoming data and perhaps how buffering differs between Roon playback and file playback. I’m anxious to see what Peregrino finds out from Signalyst.
Out of curiosity, I’m playing a song with Pipeline SDM not checked in HQPlayer settings. It is playing just fine with no dropouts. I’m not sure whether it’s best to have Pipeline SDM checked or unchecked.
[REDACTED: a bad guess about what Pipeline SDM does]
The HQPlayer manual likely describes the feature better.
Pipeline SDM activates all cores on a multicore (i7) CPU.
From a post by Miska:
“(Pipeline SDM) …splits work into more CPU cores, but it happens in such place that there is also considerable overhead for doing so. Thus it should be used only when there are number of real cores (four or more) and some of those cores max out and results in drop outs.”
Thanks. I’m removing my bad guess.
No problem 
Trying to get to grips with how HQPlayer operates.