As per the title; and what if any is (and will be) configurable?
We do not have up-sampling capabilities right now, but it’s something we are hoping to add at some point in the near future–still working out the details of exactly where the DSP implementation will come from and what it will look like.
We downsample for hardware compatibility purposes only. If your hardware (local or networked) is incapable of accepting the audio at its native rate, we cut the sample rate in half until we get to a compatible rate. This is accomplished using a couple of very high-quality synchronous SRC implementations developed at Meridian.
The next build (in alpha later today, I hope) will include a “maximum sample rate” configuration setting to accommodate downstream DACs with sample rate limitations.
Hi,
Well upsampling exists now when one checks the box crossafde time or volume levelling (upsample from 16 bits to 24bits). but doesnt change the frenquency. It does the same for DSD files which is a pitty since the SQ is poorer. No possibility to avoid this only for DSD, keeping allowing it for red book 16/44.4 files ?
Thanks
Expanding from 16-24 bits is not considered upsampling–that’s just zero-padding, and it’s a bit-perfect operation.
Generally that’s done to provide more headroom for subsequent DSP operations, but sometimes it’s done to maintain compatibility with a device that won’t take 16-bit samples directly.
DSD is not amenable to being processed directly–even something simple like a gain adjustment requires, at minimum, an intermediate multi-bit sample format. If the result of that processing is to be played as DSD, it must be re-modulated back to a 1-bit format. This manifests as a sort of collateral damage–yeah, the gain adjustment itself is a simple thing, but converting the DSD into and out of a form where it can be manipulated freely has tradeoffs and costs.
These issues constitute one of the most significant downsides to DSD-as-a-format. For a good technical primer on signal processing and DSD, I recomend this paper.
Roon currently (and in the upcoming 1.3 release) processes DSD only after converting it to PCM. Roon 1.3 is capable of then re-modulating that processed PCM signal back into DSD (so signal paths where content starts as DSD and ends as DSD with processing in the middle are possible).
When you say the DSD is converted to PCM, does it downsample to a standard PCM rate, or is it preformed at the same sample rate as the original DSD format? This is widely considered as “DSD Wide” or “PCM Narrow”, and a far superior way to do things than downsample to a lower PCM rate. At the time of the 15 year old whitepaper you shared, this wasn’t a feature standard in the DAW workstations. We have also gone up to much higher sample rates which mitigates most of the downsides of yesteryear.
This is how both Hqplayer and Daphile does the DSD upsampling. Along as some of the DAW workstations, as well as all modern SDM DAC chips. If it’s done this way the “collateral damage” is minimal, and still results in superior results if used with a pure DSD DAC. If the DAC chip in the DAC does another round of multi-bit conversion for it’s internal DSP functions such as volume control, (ie Sabre) then yes the cons can outweigh the pros.
Another equation often overlooked is if your modulator is far superior to the modulator in the DAC chip, (as it should be) the pro’s of using your software based modulator to upsample to DSD so you can bypass the on-chip modulator with DAC’s with DSD bypass mode, or pure DSD DAC’s, will far outweigh sending the DAC PCM so the resource constrained chip is left to the task.
Of course this is much more resource intensive doing it this way. However if you offered a choice of doing it the best way for those with the horsepower on tap, and also the other way which consumes less resources, then it should be a non issue.
To add to this, all modern ADC’s used to convert the original analog signal to digital at the studio use SDM technology. So in the DAW workstation it must do a conversion to PCM at that point using the algorithms in the workstation. These algorithms preform the exact same “collateral damage” as when it’s done further down the chain in either software based SRC/SDM or DAC chips. When the audio is kept in DSD, this “collateral damage” hasn’t had to happen yet. If sent direct to a pure DSD DAC at it’s native rate, it never has to happen. This is the purest path possible. However for resolutions below DSD 256 there’s benefit’s to passing it through another modulator to take the out of band noise further out of the audible band. It also allows the DAC designer to raise the low pass filter points much higher in order to take the phase shift further out of the audible band. So as long as your modulator in Roon as at least on par with what you find in modern DAW work stations, the collateral damage won’t be any more than all of the native PCM material available. Then you get the benefit of optimizing the DAC to the modulator in the software as well. Because it’s impossible to achieve with random files from random studio’s in random rates. The DAC will always be delivered music with the exact same noise profile.
The reason DAC designers who use mediocre FPGA or ASIC chip based SRC/SDM complain about the “collateral damage” of doing this in their gear is simply due to them not having near enough resources on tap to do it at the same level as the studio DAW. However with 64 bit software and Intel I7 processors this is a non issue.
You’re telling me a bunch of things I already know 
.
We won’t support DSD-wide processing yet. Intermediate handling will be at DXD rates for now. We will probably move that way in the future, but for now it’s one step at a time.
The DSP involved isn’t the hard part–getting it packaged up in a way that it’s useful, not confusing, and easy to use is. We have a much wider spectrum of user expertise and expectations to deal with than something like HQPlayer, and a significantly larger user base. Our users and our hardware partners are constantly pushing us towards smaller, quieter, fanless systems. People with i7’s are a minority in our world.
There are also some complexities when dealing with 3rd party DSP vendors, which is something we are working on for the future–not all of them are interested in getting involved in this kind of thing.
We are going to see how releasing our first round of DSP features in Roon 1.3 goes. If we find that people can manage the performance/capability tradeoffs of their hardware without creating overload for our support team, it will make it easier to move in this direction.
I suppose how it sounds is what matters. If you can at least match the SoX DSD upsampling Daphile uses, and have an option of 7th order modulator, that won’t be bad. Most DSD that people upsample will be single rate anyways. In Pyramix they convert single rate DSD to DxD for processing just the same.
I know most don’t have powerhouse computers to handle powerful algorithms. But they also don’t need to use the feature if it’s available as well. Daphile’s top SRC/SDM algorithms are more CPU demanding than HQP. But 99% of the users won’t use them anyways. However since we make a DAC specifically made for DSD 256 and 7th order software based modulators, it’s quite important for us.
Thank you for your answer, very clear.
When you say “Roon currently (and in the upcoming 1.3 release) processes DSD only after converting it to PCM”, actually it is DOP (DSD over PCM) and I believe it is bit perfect, since the final signal is DSD as the original (DOP is only a way of conveying the 1 bits after one bits signal by packages of 16bits which are resplit in the same 1 bit after 1 bit at the arrival (instead of 1bit by 1 bit all the route), which is different than converting into PCM and playing PCM at the arrival. This is what appears to be in the received signal analysis of my DAC.
When I said “convert to PCM” I wasn’t talking about DoP, which is indeed bit-perfect. I was talking about an actual conversion (downsampling) to PCM.
OK you indeed mentionned it in the case it was “processed”, my mistake.
Will the DSP coming with 1.3 be having an option to differentiate treatment prefered based on format DSD or PCM ?
Thanks
What would be a potential difference in treatment? If any application of DSP, the format must be PCM – either native PCM or converted DSD.
AJ
Indeed. So my point is can we have an option in the DSP saying : please convert PCM 16bits to 24 bits and leave as it is DSD files. With 1.2 if I convert PCM, DSD is also converted (wich results in a significant lower SQ with my DAC than direct DSD(DOP)
I do not follow you. Under Roon 1.2, your settings for PCM and DSD already can be maintained separately by opting not to convert DSD to PCM.
AJ
So what if none of the DSP features are being utilized, and you playback native DSD 64 and 128 and choose to upsample to 256? Does it go direct to the modulator, or does it downsample to DxD first then re-modulate? With HQP, if you want to upsample DSD to a higher rate you have no choice but to do the multi-bit conversion. The only way to bypass any multi-bit conversion with HQP is by selecting “SDM direct”. In this case you can’t upsample DSD. It simply passes it through un-touched at the native rate of the file.
Well, nope. When i don’t select Crossfade or volume adjusting, everything is unchanged PCM and DSD are bit perfect (DSD is DOP which is OK). When I choose cross fade or volume levelling PCM 16bits is converted to 24 bits which is fine and considered bit perfect since it adds only zeros … but DSD is converted to PCM. I d’ont find how to leave DSD as it is (= DOP)
Because that is not possible. DSP is not possible to apply to DSD. Hence, if DSP enters the signal path, then DSD must be converted to PCM. That has been explained prior in this thread.
AJ
How about you play with it, and look at the signal path when 1.3 launches, then give us some feedback about what your priorities are for improvements. It will be easier and faster than asking me about each “what-if” one at a time
1 Like
Sounds great! I would love to do that today
2 suggestions :
1 - it would be great to be able to decide the signal outpout treatment based on the signal input. I mean something like for instance ;
- DSD -> Unchanged
- PCM 24/96 -> Unchanged
- PCM 16/44 -> Upsample Max X2…
… instead of having the same DSP treamtment for all. This is a feature available for many DSPs on the market (like Jriver)
2 - Why 16->24/32 bits enhancement is not possible directly with the DSP - I need to add a cross-fade time for having this happen ?
Thank you