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.

Mysterious indeed. I assume you have tried both the regular AVX2 build and the "Intel" build?

It should work at least through BlackHole. Since I understand it also includes video, you can try using either of the "short buffer" modes to reduce the delay. With Short Buffer checked and Blocks per cycle something like 1 - 4, it should be OK'ish for video, depending on selected filter. Minimum phase filters give lowest delay.

Noble packages won't work on Jammy. But you should be able to easily upgrade your Jammy to Noble.

Please try for example 6 instead. Value of 1 gets rather inefficient especially with GPU. Since you have just one GPU, I recommend leaving both GPU selections to "Default". Not that it should make any difference here, but just in case.

Yes, exactly. You can also upsample to higher DSD rate at the same time if you like (and of course also convert to lower DSD rate if needed). Upsampling gives you also some extra bandwidth and headroom. "Integrator", "Conversion" and "Modulator" choice applies, although "Conversion" only if you choose to change output rate from the original. You can see what is happening for example from HQPlayer Client. Some other settings also has effect, such as "Adaptive rate" and "Bit rate (/Limit)".

If you have matrix processor enabled, then Direct SDM is pretty much ignored (apart from locked volume control). But obviously things like DAC correction and Direct SDM are mutually exclusive. Otherwise, source content format doesn't matter, it is output post-process plugin anyway.

Considering what I remember your earlier posts, you have Nvidia GPU? Please make sure you are running latest Nvidia Studio driver from here: https://www.nvidia.com/en-us/geforce/drivers/ And check that you have CUDA offload enabled. In "Download Type" select "Studio Driver" unless you are doing some gaming with the same computer (in which case you should choose "Game Ready"). If the driver is too old, CUDA offload will either drop off, or behave incorrectly. In general, every time HQPlayer release mentions "component updates", it is worth checking you are using latest driver. Also check that you have "High Performance" or "Ultimate Performance" power profile selected in Windows. Ultimate Performance power profile is normally available only in Windows for Workstations versions, but it is easy to hack into regular Windows Pro as well. Although I have not compared carefully whether it works the same though, since there are other differences between these OS versions too, in particular with the Windows kernel.

Yeah, as mentioned earlier. Without DAC correction (and without CUDA), 13900T can do DSD1024 with ASDM7EC-light and same settings. And 14900K can do DSD1024 with ASDM7EC-super. So DAC correction at least doubles the load, without help of CUDA. Nvidia GPUs scale better and the difference is not as drastic with GPU offload. Both of these machines have the same DDR5-6400 CL32 RAM (G.Skill).

It is the original Founder's Edition manufactured by ASUS. So it looks exactly like the ones in Nvidia's pictures (one barrel fan at the end).

Without GPU, maximum 13900T can do is DSD256. While 14900K can just barely keep up with DSD512 with ASDM7EC-light, super is too much: This is with E-cores set to filter. With help of RTX2080 the 13900T can do DSD512 with ASDM7EC-super 512+fs with DAC corrections easily.