As in PCM up-sampling, the higher is better; the image frequency of 44.1kHz is thus move up all the way 352.8kHz so it is much easier to filter off. Most off selves DAC chips employed 8x over sampling as a default which max out to 352.8/384k, but some can go up to 705.8/768k.
Software up-sampling like in Roon done together with an NOS DAC enable better flexibility on sampling rate and the choice of programmable digital filters.
Thanks, so unlike DSD upsampling which may have phase noise and jitter problems the higher you go (above DSD128), there are no downsides to going higher with PCM up-sampling rates if the DAC chip supports it?
That discussion about clocks is not DSD-specificâŚitâs just that PCM rates are less demanding because they are smaller.
There is an advantage to going higher with an NOS DACâthe perfect analog reconstruction of a PCM stream should look like an infinitely high-resolution sinusoidal interpolation between the samples. Itâs the DACâs job to approximate this, but it is limited by the-physics-of-how-resistor-ladders-work in ways that DSP isnât. So by upsampling, youâre giving the DAC more points, which may reduce the difference between âidealâ interpolation and what the DAC would have done if driven at a lower sample rate.
Iâm not sure of downsides aside from the typical (CPU usage, heat). I tend to drive NOS DACs at their maximum supported rate.
BTW, I wouldnât class the iDAC2 as âNOSââthat term is generally reserved for a ladder DAC driven by a totally un-processed data stream. It could be stretched to other multi-bit converters provided that there is no digital processing applied to the data prior to conversion, but I donât think it applies here (and I donât think iFi markets this product as NOS either).
The iFi uses a S-D architecture chipdac from Burr Brown. It looks like there is a narrow multi-put path in there that iFi is using in a hybrid arrangement. The multi-bit section is not R2R based, and there is definitely digital domain processing going on there, at the very least, to split off the lower bits of the stream and get them ready for the S-D portion. This is how they describe it:
The DAC chip we use in the iDSD nano offers a rather unusual way to handle things. It uses a 6-bit true Multi-bit DAC for the upper 6-bits of PCM Audio and delivers the warmth and slam Burr Brown Multi-bit DACâs are so famous for. Any bits below this are converted with a low order 256 speed Delta Sigma modulator (in effect DSD256), giving PCM playback the smoothness Delta Sigma DACâs and DSD are famed for. (From here)
My guess is: their âbit-perfectâ mode ensures that the top 6 bits of the PCM data wind up in the multibit pathway unmodifiedâi.e. there is no filter applied beforehandâbut I donât have any special knowledge about this product to tell you for sure.
Brilliant as usual - thanks Brian.
I only mentioned NOS myself because, regarding the bit-perfect mode for there DACs they say:
âThe least complex digital filter is a zero order digital filter, also known as âno filterâ or Non-Oversampling. At AMR/iFi we call this type filter âBit-Perfectâ because it is the only digital filter that is bit-perfect (it does what it says on the tin). It has a perfect impulse response but equally it has absolutely no filter action.â
So your guess is 100% correct (as usual)
Thanks mate
PS from this below Technical Note I wonder if itâs best to up-sampling to DSD128 in Roon - even though their DAC supports DSD256, I suspect phase noise and jitter may be a problem? Unless itâs a CPU issue that they limit it to DSD128.
I might pose the question to iFi.
I donât have a strong feeling either way.
Iâm not totally clear on whether this DAC is internally oversampling DSD128->256. The block diagram suggests that the SDM portion always runs at 256fs, but doesnât show where that happens with a DSD source. If it is oversampling the DSD, that is a step I usually prefer to bypass.
Phase noise/jitter (in this contextâdiscussing whether the clock performs better at DSD128 vs 256) is further down the food chain in terms of important audible concerns, when compared to bypassing DAC-side oversampling stages IMO.
Thanks Brian.
Agreed, their marketing says "True NativeÂŽ playback on DSD and PCM. What does this mean? the iDAC2 (and all other iFi DACs) will keep the integrity of the file format unchanged all the way through. "
I too hope a DSD128 source isnât being oversampled internally to DSD256. Iâll ask the question. Then again, if Roon can up-sample to DSD256 then there be no oversampling happening anyway according to their block diagram. But then thereâs the phase noise thing again.
I wonder if the people up-sampling to DSD512 with the iDSD that say the sound is much smoother, are actually enjoying more jitter (due to higher phase noise). Iâve often found higher jitter makes things sound smoother. I had an iDSD BL before also. And perhaps why the DirecStream DAC (which I have) and Playback Designs DACs limit outputs to DSD128.
I wouldnât read too far into this, especially for designs that have been around a little while. Doubling the sample rate puts more performance pressure on the whole system. Handling DSD256 and beyond over USB didnât become a commodity capability immediately. Now there are good off-the-shelf USB interface solutions, stable drivers, etc. It wasnât always that easy.
If those products were designed in 2017, would they still put the limit at DSD128? Current Playback Designs products go up to DSD256. So clearly it doesnât sound so bad that they canât stand behind it in their products 
I understand the line of thinking. DSD128 is enough of a data rate, and puts the filter in a significantly better place than DSD64, and the DSD256+ benefits are maybe not as clear when stacked against the performance cost.
Andreasâs article did say something interesting:
Until fully integrated DAC chipsets are available that convert DSD signals without any digital processing, it appears that the most impact that quad DSD may have is at the A/D converter end of the chain. This means that for now quad DSD may be limited as a delivery format, because direct conversion to analog is still problematic.
This implies that at least some of his objections disappear in the case of a discrete DSD DAC that doesnât perform digital processing. I donât remember if there were any of these in 2015 when the article was written, but there are definitely some of those out in the world nowâHOLO Spring, and T+A DAC-8 DSD are the two that Iâve spent some time with.
And which one did you like better?
Great points Brian - lots have things have improved over the last 2 years since that was written, as you said.
Lots of great options out there today and more options continue to improve at a rapid pace.
Wow, just wow. Great discussion, but most of it is too in the weeds for my old brain to follow.
About jitter. Iâm assuming that upsampling takes place in the Roon core. If thatâs true would a reclocker take care of any potential jitter artifacts created by upsampling?
Iâve used T+A mostly with headphones and Holo Spring mostly with speakers, so itâs difficult to directly compare. I like them both a lot. I have spent more time with the T+A since it drove my headphones for a while. The Spring is more difficult for me to integrate day-to-day because it lacks a volume control.
Also, I have the base model Spring, not the âtunedâ version that most people seem to be buying.
The T+A is more polished product. It has more built-in functionality, a volume control and a good headphone amp (unless you have big power requirements). It sounds markedly different playing DSD vs PCMâand I like the DSD sound better.
The Spring is a âblank slateâ. Itâs great for playing with DSP because of its NOS modes, i2s input, better linux support (at least for now), etc. If you like tweaking around with all of the different stuff in the system, it provides more opportunities.
To my ears, the Spring sounds like a ladder DAC. The T+A feels slightly more precise. I donât find one to be head and shoulders above the otherâŚjust different sounds. Really, different products for different kinds of people.
Jitter is not an artifact created by upsampling, and is not transmissible from core->DAC unless you are using a mechanism that mixes clock reference + data like S/PDIF. With S/PDIF and things like it, reclocking helps.
This conversation totally concerns whatâs happening inside of the DAC.
DACs have a clock generator that typically runs at a very high rate (in the iFi DAC we were talking about, it has two, one clock that pulses 44100*512 pulses/sec, and one at 48000x512 pulses/sec).
These clocks determine the timing when individual samples are rendered into sound. Jitter is the timing error in those pulses. This is essentially random. On average the clock will keep time at the stated rate more or less, but individual pulses can be positioned +/- a certain amount depending on the accuracy of the clock.
Lets say youâre running the DAC at the DSD512 sample rateâthat happens to exactly match the 44100*512 clock in the iDAC2. So one clock pulse = one sample. Each pulseâs error amount directly translates influences the temporal position of one audio sample.
But lets say, youâre running the DAC at 44.1kHzâthe DAC is going to use the same clock, but only look at every 512th pulse. The expected timing error in these âdividedâ pulses is 512x smaller relative to the sample rate (and thatâs what matters here). So the samples are positioned more accurately, and there is less jitter.
Most DACs (oversampling DACs) render their output at the same rate all the time, so they are seeing the same behavior with respect to jitter regardless of the source material.
Other DACs (NOS or non-oversampling DACs) match their sample rate to the source material, and might experience less jitter-related artifacts at lower sampling rates than at higher sampling rates. This discussion is really about these.
I believe the term âTrue Nativeâ hardly exist anymore. To say, bit format has to match exactly to the hardware. In the case of Holo Spring DAC, PCM 24 bit format is a exact match to the 24 bit ladder R2R. However, DSD is not, Spring uses 6 bit, 32 discrete level DSD conversion, it is not a true â1 bitâ SDM.
True 1 bit SDM such as BB PCM1792, 1795, CS4398, AK4490 are few examples but ESS Sabre for example uses 6 bit discrete level to convert DSD to analogue. So having one chip to process both PCM and DSD, thereâs always a trade off, unless someone make a R2R and SDM inside a chip or a module, then I think true native will deserve its title.
Please can you provide a link for that info?
@joel, I got the information from designer, Jeff Zhu, you can email to him to find out more. Discrete DSD conversion is used in Chord, MSB, DSC-1 and Denafrips, just to name a few, which also uses R2R for PCM conversion. One example is entry level Ares below:
Great, dense info. Sorry to be a PITA, but why do companies make devices that reclock that USB signal before it goes to the DAC? Donât understand.
Almost all DACs are asynchronous, meaning it doesnât use the incoming source clock to synchronised the data, instead it is âreclockedâ internally by generating a highly stable and low noise clock. This significantly reduces jitter and phase noise to the DAC chip. Moreover two separate crystal clocks for 44.1k and 48kHz multiple can be used.
So, for asynchronous DACs these devices, e.g. iFi USB, Allo USBridge, ReGen, etc., etc., are completely useless? At least as far as jitter is concerned.
Thanks for your reply.
I would say, jitter is no longer dependent on the incoming source clock. Of course, jitter is still dependent on the internal clock; so how well designed the internal reclocking mechanism, type of crystal oscillators and power supply also influenced that. However we remove one of bottom neck of high jitter from incoming source clock.
Good question. I would think they are indeed useless when it comes to asynchronous DACs as the clock is being regenerated in the DAC anyway. There may be other sources of noise that it helps with thoughâŚ
A nice high level explanation was given here by my DACâs designer of what the Regen is doing:
I can only guess similar would apply to similar devices (like your iUSB3.0 Slim).
