Miska

Yes, this is what I've been saying, because it natively only supports these two rates, nothing else. DSD64 although works as well, but it is not recommended and kind of "underclocking" thing. I would say DSD64 should be always played through some upsampling, just like 44.1/48k PCM.

And if one has Nvidia GPU, whenever updating HQPlayer it is also good time to check whether there is a new Studio Driver available from Nvidia (or Game Ready if the computer is also used for gaming). It is also good practice to uninstall previous version before installing new one. This cleans up old file versions from the program files folder so that there is no cumulative growth of unused files there. It shouldn't have functional effect though...

Specification compliant / certified USB3 cables do have a very good shielding and separation.

That will probably also work, but I cannot comment much on such special cables. Maybe it is a good cable, I don't know... I just use regular cheap cables with official USB certification badge. USB2 thus USB HiSpeed certified and USB3 thus USB SuperSpeed certified.

Do you get any display visible from HQPlayer, or it doesn't even start? You selected the 6.6.50 kernel from grub boot menu? By default it won't boot my kernel but instead the stock one. You can always select which one you want to boot, so no need to uninstall anything to switch. HQPlayer used to work on the same machine before OS upgrade? No, libgmpris is only needed by HQPlayer Embedded. Never needed for Desktop. You don't need to use my custom kernel unless you need some of it's features. You can try to start HQPlayer from the terminal and see if it spits out any error when it's closing down. You can just open terminal and issue "hqplayer5desktop" command.

Holo Audio and iFi DACs have USB3 interfaces, and I would strongly recommend to use those when possible. USB3 has better power delivery and much better cable specs than USB2. In particular USB3 separates the power feeds better from the data. And also data wires are much higher spec.

No, 5th order is somewhat lighter than the 7th order one. In theory, however, practice is more complex. Like we've seen doing DSD1024 with the 512+fs modulators which should be lighter while they are not in practice. Please note that when you run into frequent stutter, all load figures are pretty much meaningless. So in such case you need to drop the output rate to something that doesn't stutter and compare then. Then you can extrapolate that doubling output rate roughly doubles the load figures. You can also check if it is CPU or GPU bound by keeping same settings and enabling/disabling CUDA offload. With 14700K I recommend setting E-cores to "filter" when not using GPU, although not sure how well it is going to work with this particular filter.

Yes, that's the case. But if you have multiple HQPlayer servers, each can play to a different DAC behind a single NAA. Or one HQPlayer server can use input side of a NAA and another one output side.

Can you explain how did you try and which way it didn't work?

Yes you can. With NAA v5 you can even have multiple inputs and outputs active simultaneously.

I don't see HQPlayer doing work on the GPU in either of these cases... You could also try booting to the stock Ubuntu kernel and compare if it makes a difference for you.

What is the source media? Sometimes it is not relevant and then shown empty. For example if you play a local file natively. For streaming or realtime (input) sources it is usually shown. "Buffer time" = "Default" means "use the one suggested by the driver" which would be 2048 samples in this case. "Short buf" setting adjusts size of the FIFO that is between HQPlayer and the audio driver. This is the one of which you also have that bar indication in HQPlayer Client (the lower one). The upper one is input side FIFO level when source is hardware input. And if it is for example a streaming source, it is fill level of the streaming buffer. So we have two different buffers in play here. One is the low level hardware DMA buffer owned by the audio driver. And another one is the FIFO buffer at HQPlayer or NAA side that is between all the playback operations and the hardware buffer. The hardware buffer is much smaller one. Hardware buffer deals with just bare low level OS timing inconsistencies (delays). While the higher level FIFO can handle much bigger delays due to badly behaving applications within the OS or network traffic inconsistencies.

You only need to Nvidia kernel modules (drivers), nothing else. For HQPlayer Desktop you naturally also need the graphics drivers. For Embedded those are not needed. If you are using Intel CPU with integrated graphics, you can try to use display output from the GPU inside CPU package and leave the Nvidia GPU just for CUDA. There is no need to reinstall, since you can make changes and as long as you use the packaging system you pretty much know state of your system (unlike on Windows). Looking at those figures, it seems it has more to do with GPU overload or otherwise limiting performance than anything else. But please make sure you have otherwise exactly same settings. So you can try to export/import the settings file across platforms. Is there any difference in nvidia-smi output between Windows and Linux? Instead of reinstalling Ubuntu once again, you could also try Fedora Workstation 39 and see if it makes any difference. Sometimes it will, but it is a bit more of drill regarding OS updates, as it movs much quicker than Ubuntu LTS editions. That's why also Nvidia is always behind...

For measuring you should use a linear phase filter. Otherwise you may get strange results, in particular if you use minimum phase filter for measurement and then switch to a linear phase one. But you don't such challenges if you measure with a linear phase filter and then use a minimum phase one for playback. You could try to use the HQPlayer input feature with lowest delay setting. But for room measurements it may not be worth the trouble, instead you could just run May straight with 352.8k measurement. Your measurement to measurement variation in room will be more than what you win by making life more complex. For making it useful to run through the full chain, you need to statistically lower the natural acoustic variation which means you'd likely need to make couple of hundred or thousand measurements and combine those. For example being physically present during the measurement tends to create variation unless you can hold your breath and stand still for the entire measurement cycle. In relatively quiet environment, breathing pumps the environmental noise couple of dB.

Why are you asking me about mpd? I have never used mpd and it is not related to what I do in any way. HQPlayer NAA thread is wrong place to ask anyway.