Even though “Network Audio backend” buffer time is something within digital domain, it can be used to tweak the sound phase, which means it changes when low & high frequncy part of the audio arrives on your ear. Kind of like zooming a camera, I can get a pretty accurate & comfortable result out of that by changing “buffer time”.
NAA(Networkaudiod) on Windows basically has much better phase accuracy than linux NAA. I guess the reason is customized ASIO driver.
Very interesting.
I thought I’d seen every sound quality tweak before but this is a first for me ! 
I’m very happy leaving default values on NAA OS though.
I measure my DAC analogue output (from NAA OS) and don’t see any phase issues in measurements.
it’s not an issue though. You may also hear minor difference by changing ASIO buffer time on HQPlayer Desktop, or elevating process to ‘realtime’ priority in task manager. I think they’re the same thing. It’s all about your taste and quite subjective.
That is bad idea. HQPlayer already assigns suitable priorities to different threads, based on what kind of task those are executing. Timing critical threads are already running at realtime priority. If you lift the entire process to realtime priority, you may have issues, because you end up running the graphical user interface threads at higher priority than for example the audio processing threads. Potentially starving more critical activities by giving higher priority to less important thing.
There’s no way you can externally control the priorities in a sensible way, because you don’t know what the hundreds of different threads inside HQPlayer are doing.
Threads also come and go frequently during the execution time, and when they are created they are assigned correct priorities. So your external setting won’t “stick” to anything else than the graphical front-end.
it seems to be unecessary to worry about this. Just found out how Windows arrange process & thread priority
Process priotity & thread priority, they’re not on the same dimension.
When I raise priority of a process, all threads created by the process correspondingly has higher priority compared to threads from other processes.
But thread priority within the process stays the same, time-critical threads won’t starve because it still has highest prority.
That is the old system, not applicable anymore to the latest Windows versions and with MMCSS (which is used by HQPlayer) etc.
Also remember that HQPlayer depends on number of Windows OS services which also have their own priorities. You don’t want HQPlayer graphical user interface, or some unimportant thread, to starve some OS service that is critical for HQPlayer’s audio operations. For example from that table, even idle priority thread of real-time class would starve normal class time-critical thread. At most high class gives you safety against this. In worst case, you risk having your system deadlock.
So generally, don’t mess with these. HQPlayer already assigns carefully designed process and thread priorities, and various other QoS things internally, by itself. This things have been tuned for optimal performance over many many years.
