These were already in there prior to 233/234. I’m with you, though, on the desire to learn more about the differences between precise and smooth and also among the different SDM’s. Meanwhile there’s some info here:
Thanks! I did not notice the division into precise and smooth before. There have been several updates since I did a write-up about 1.3, but it wasn’t until 234 that I found out about this.
I was completely happy with Minimal Phase filtering the way it was (turns out it became Precise, Minimal Phase an unknown number of versions ago) but I’m a sucker for ‘smooth’ no matter what you throw it at as an adjective
We’ll see (or better: hear) what happens when I change the setting.
It’s strange how my expectations of which filter I would like don’t match my ears. With Roon I prefer Smooth (meaning the cutoff at 22kHz is a gentler slope, enabling a shorter filter in the time domain and a cleaner transient with less pre and post ringing) but my new favourite filter combination is HQP ext at DSD 256 (DSD7 modulator). This is a long filter, a la Chord, with lots of taps and a fair bit of both pre and post ringing, but a very steep precise brick wall in the frequency domain at 22kHz. I find the soundstage magnificent and the ringing euphonious. But I would never have picked that combination as likely to be my favourite.
As for the new ‘precise’ vs. ‘smooth’ filters – the release notes tell this:
New SRC filter choices: Smooth vs Precise filters. The Precise filters are steeper than the old ones, but designed around similar goals. The Smooth filters are ultra-slow-roll-off filters optimized for a very clean transient response. “Precise, Minimum Phase” is the new default.
Upsampling consists of stuffing the original sample with zeros and then applying a low pass interpolation filter to eliminate an alias (in frequency domain) or smooth discontinuities (in time domain). There is some theory here and a much more fun interactive demonstration here.
I notice any x48 pcm rates being converted to DSD128 brings my machine to it’s knees and eventually causes a transport error.
44.1, 88.2, etc are all fine and go to DSD128 with 6x processing speed.
48,96, etc all show a load of < .6x processing when going to DSD128.
I’m on an i7-2600 VM host with 4 cores dedicated to my VM, I could move to a dedicated 3770 but I’m concerned that might still not be enough to handle x48 pcm rates. It seems to be rather computationally heavy?
Maybe due to the VM? I have “Enable Native DSD Processing” on & the Roon meter stays at 2.9-3.1 no matter what PCM rate I throw at it. DSD64 too, for that matter. I’m converting everything to DSD128 like you are. This is on a lowly AMD A10-7700K machine running Win7pro.
Does anyone know why it doesn’t do the conversion to 64 bit float when the upsampling to DSD is set on custom? It also skips the upsample of the PCM to 352.8 when convolution is used in custom. Here’s the signal path difference.
Here’s a comparison comparing 24/96 tracks upsampled to DSD 256. I think I pinpointed the issue. Look at the difference in processing speed. The server is probably crapping out when upsampling in custom. The conversion to 64bit float drops the CPU load drastically for some reason. But increases the taps when using convolution. Clients reporting better sound.
I’m not Brian, but I know he’s a busy guy. And as a guy who
makes SDM DAC’s I know the answer. What it does is takes the phase shift of the filter further out of the audible 20-20khz range. It can also lower 2nd order noise caused by downstream gear that’s sensitive to ultrasonic noise.
This plot shows a similar frequency and phase response typical with DSD 64. Note how deep the phase shift goes into the audible band. This can mess up soundstage. Upsampling shifts everything further away, and by the time we get to DSD256, if the DAC has a proper analog filter for the task, no phase shift will be in the audible band.