Unfortunately, yes, that is the case. I could not try PCM>DSD as my unit had an issue with static when engaging SDM mode. This is one of the reasons why I sold it and got the R26.
I see, what a shame that you never got to experience DSD on X26Pro, it wouldāve likely killed my upgraditis before it inevitably resurfacesā¦ 
Hehe, itās bound to happen one day but I must say Iām very happy where I am now (canāt believe how long the journey has been).
I think a new record has been set on my apodising counter todayā¦ Crazy stuff (thatās just for one song). Thatās when Sinc-L gets to catch some shut-eye and M(x) takes its place, hehe.
1 Like
Has anyone been able to get 64 million taps out of Sinc-L? I can get 88/92 to 512 (32 million taps), but 44/48 playback wonāt start. Iām wondering if 64 million taps is even possible. My new PC build can now handle any filter/modulator combination at 512, but I keep coming back to sinc-L/ASDM7ECv2
For those who have tried the L family extensively in DSD mode, the longer an L filter is, the softer it gets, but it also becomes incredibly dense, velvety, ample, and grounded. It produces organically rich tones and voices, and is probably the closest thing to analog sounding I have heard in a DSD filter.
Edit: For 44/48k material, I use Roon DSP to upsample to 88/92k (linear sharp) before sending it to HQP (I know, I knowā¦). But itās the only workaround I can think of. Surprisingly, the quality loss seems to be negligible.
1 Like
Thatās bad idea. It largely negates point of running the HQPlayer filters in first place. First step up is the most critical, rest is much less important.
Are you using GPU offload? If so, you may be running out of GPU RAM. You will likely need at least 32 GB of GPU RAM. If you run it on CPU, you need about 64 GB of RAM to avoid running into crazy swap loop.
2 Likes
I know, but if itās my only option for playing 44k material @512 Sinc-L/ASDM7ECv2, Iāll take it. I thought it was going to sound terrible. But it doesnāt. Thatās very surprising! What I hear is mainly the sound signature of 512 Sinc-L/ASDM7ECv2, not that of Roon.
Maybe I need better overclocking, but out of the box, the i9-13900K does not seem to be able to play DSD512/Sinc-L/ASDM7ECv2 on its own.
A 32gb GPU costs a fortune. Letās say I add another 32GB for a total of 64gb of RAM. Will HQP be able to use the GPU for filter calculations and the computerās RAM at the same time?
Makes me think of all those 44.1kHz MQA files that get āunpackedā into 88.2kHz before being sent to the HQPlayer. Or is that actually different than upsampling in Roon first? As in - from what I know, MQA does not apply its filter until the last stage of processing which happens inside a DAC if it supports MQA. Iām not sure what upsampling algorithms are used in the first stage of the āunfoldā. I donāt think Iāve been able to hear much of a difference between a Qobuz 's 44.1 FLAC and Tidalās 44.1 MQA which gets upsampled to 88.2 (with both then being processed by the HQPlayer). But it makes me wonder what on Earth happens during that unfold when the original file is supposed to be 44.1.
I have another question thatās been on my mind recently - until I figure out how to get my DAC to accept DSD directly, I am restricted to using the DoP protocol whose limit is DSD256. Not a big deal for me as DSD256 appears to be the sweet spot anyway. However, if I am playing a 96kHZ FLAC file using DSD256 settings, my DAC will only receive the signal at 12,288kHz, effectively making it DSD128 (same frequency as DSD256, however, if Iām thinking correctly, a 96kHz file converted into DSD256 would result in the sample rate of 24,576kHz).
My question is this - from a technical point of view, if Iām listening to a recording which has been released both at 44.1kHz and 96kHz, with both being the same recording, not a re-master (e.g. Maroon 5ās āVā album), given the above limitations of the DoP on my DAC - am I better off sticking to the 44.1kHz version or does the 96kHz have inherent benefits (such as the noise already being pushed further away from the audible frequency range) that would make using this version beneficial even if I am unable to apply DSD256 processing to it?
And even putting MQA aside, all the fake hi-res out there on all the main streaming services.
We had a discussion on another HQP thread about this, just a couple days ago.
Do you have ā48k DSDā enabled but the rate limit set to ā44.1k x 256ā?
Do you have āAdaptive output rateā checked?
You might as well post a screenshot of your āSettingsā windowā¦
Yeah, likely CPU is not going to cut it. Nvidia GPU with 24 - 32 GB of RAM will probably do it. How much RAM do you have?
CPU and GPU have separate RAM. So if computing goes to GPU (which is pretty much needed for the case you want), you need to have the RAM at GPU side. CPU with 64 GB of RAM will hold the data, but the memory bus will likely just choke on the bandwidth requirement. Big GPUs have much faster memory interfaces, the heaviest ones use HBM.
1 Like
Yes, 13,9k/4090 did 512 even with sincMX.
1 Like
Yes it is different. āFirst MQA unfoldā is just unpacking to 2x rate. This is what Roon can do before sending the data to HQPlayer. So it is not upsampling. Then further āunfoldsā are just upsampling with super leaky MQAās filters, but Roon wonāt do that for you.
The loss is in dynamic range. The bits required to represent the 2x band above base bandwidth have to be stolen from the base band. So typically MQA āunfoldsā to 13 - 17 bit output.
For best performance just let Roon to do the first unfold to 2x rate before sending it to HQPlayer. In case you need to use Tidal/MQA, instead of Qobuz or some other lossless.
12.288 is DSD256 = 48000 x 256 = 12288000
24.2576 MHz is DSD512, IOW, 48k x512.
You should always use the original recording resolution whenever possible. If it has been recorded in 96/24, then use the 96k version. Thereās a lot of fake hires out there, so it is not very easy. But if you are reasonably certain that the content is originally hires, then it is better choice.
1 Like
Yes. 
lots of vram usageā¦ Iām sure the type of music will have an impact on how it uses the GPU. I just picked some classical.
Iām even using firefox in ubuntu to post this and itās still playing dropout free. I highly recommend the deepcool lt720 aio. I canāt even hear the hqp player machine running and the temps havenāt gone above 75c! 
- cpu usage: ~8-10%
- cpu temp: ranges 40-75c
- ram: ~20G
- gpu usage: 20-66%
- gpu mem: 11.9 of 12G
- gpu temp 40c
44.1/24 ā sinc-L 7ECv2 DSD512
48/24 ā sinc-L 7ECv2 DSD512 48k
Any idea of how to check/control that it is an original hires?
For example using audio editor and check out the spectrogram. Free Audacity is enough for the purpose. Unfortunately you will only know after buying if it was real or fakeā¦
2 Likes
Nice! And how do you like Sinc-L with 64 million taps? How would you compare it to Sinc-Ll with 32?
I always like sinc-Lm. This is the first time I ever tried sinc-L from 44.1. I was intrigued by the ram usage and was seriously expecting more cpu usage. Iāll have to sit down and listen now.
And now that this build is (dare I say it) 
stable 
ā¦ Iāll attempt to stop messing with it.
@jussi_laako Sorry if my original post wasnāt clear enough.
What I meant is that, unless Iām missing something, a 96kHz file would need to be upsampled 128 times in order to reach the same frequency (what we would refer to as DSD256) as a 48kHz file would when upsampled 256 times (same for 44.1 vs 88.2, of course, just different frequencies). This appears to be confirmed by both the time it takes for a song to play as well as the RAM usage which is halved when Iām playing a file that is already higher-res (leaving aside the issue of whether it was actually recorded at said higher-res or if it was upsampled afterwards).
If my thinking is correct, then my two issues would be:
-
Does using 44.1/48kHz provide the HQPlayer with more opportunities to filter out the noise (more upsampling cycles/higher conversion ratio = the noise being pushed further away from the audible frequency range)? Or, perhaps (as Iāve alluded to above) - it does not matter because the higher-res content already has the noise pushed further into the āabyssā? (Talking about conversion into DSD, though, and the noise that is created in the process.)
-
With filters such as Sinc-L and Sinc-M(x), using higher-res files would appear to decrease the number of taps that are applied (lower conversion ratio = fewer taps). Again - perhaps itās not that relevant to the content that is already higher-res to begin with.
I used to use Spek as it was very lightweight. I recall having issues with it before but that was a few OSās ago, and the way I tinker with things, it was probably something I did that screwed it up. 
Filter length is altered to retain same characteristics regardless of conversion ratio. So for smaller ratio you need less taps to retain same response.