Am I right in thinking you can go optical directly into the Phantom (ignoring Dialogue) as well as optical into the Dialogue itself? Are you both connecting the same way - seems odd the outcome would be different for each of you?
You could, but everything needs to be in the same proximity. I am streaming wirelessly thru the Dialog. Also I have two Phantoms and you need to utilize the Dialog to connect to two Phantoms.
And donât forget all of you Phantom owners (if you havenât already) - email Devialet support and tell them you want Phantoms to be made RoonReady so you can go natively into them, including DSD and with volume control.
Devialet think you dont want this and would prefer to use Spark ;);)
Definitely weird as Andrew at Sonore got the same result I did with signal chain conversion of 352 to 44k.
you can use the optical input on either the Phantom or the Dialogue - no difference - If you have more than 1 phantom, you can use the additional inputs too - all controlled from the Spark app.
My DSD64 files downsample to 176.4 as shown above.
Something to do with the RAAT protocol vs the Squeezebox protocol? Try putting the Sonicorbiter into squeezebox mode and trying again with Roon using the Sonicorbiter as a squeezeplay endpoint.
Trying it now. Thanks.
Okay. I have some answers. I was just on the phone with Andrew from Sonore who was talking with the Roon guys. My Squeezlite app works and I get a similar sampling rate at 176. A couple of issues to think about. With Andrew on the line we confirmed that the Sonore box, in the Squeezlite mode is indeed UPSAMPLING the 176 file conversion to 192 and playing the DSD files at 24/192. The issue comes in to play here is you are using the processor in the Sonore to do this and not RAAT in Roon Ready mode. Andrew has said Roon does not want to get into the redithering business of upsamling music. So this could be the case for the RPi2 as well when it becomes Roon Ready. I suspect it will downsample to 44k as well. Roon could add this to there Roon Ready devices and would be huge. I can confirm my DSD64, DSD128 and DSD256 files sound so much better using the Squeezlite setting and having the Sonore processor upsample than having Roon do it. The sonore has a web interface page where you can actually see what the file is being played and sampled at. Food for thought going forward.
The upsampling of 176kHz to 192kHz is just plain weird: thereâs nothing to be gained and much to be lost. The only reason for doing this is when your DAC is not be able to accept 176kHz. Is the Phantom able to accept 176kHZ?
Iâm in a kind of similar situation, running a Pi w/ squeezelite, limited to 96kHz in Roon. Roon downsamples DSD exactly as it should, with proper rate conversion:
The limiting of downsampled DSD to 44.1kHz in RoonReady/RAAT mode sounds like a bug to me, but not having any experience with RAAT thatâs just guessing.
The Phanom input is optical with a max of 192.
Do you have the Soniorbiter software set so that the output is fixed 192/24 for the optical? Maybe thatâs why itâs upsampling. Thereâs no need to do that if you are, the Dialog/Phantom will aceept rates below that.
On my RPi2/Digi+ setup, the optical port outputs whatever Roon sends, with no up or down sampling. So my Dialog/Phantom gets 176.4 which is what Roon is sending
You hit the nail on the head. I think the Phantoms likely donât accept a 176 signal and that is why is is being up sampled to 192. That was Andrews take at Sonore. But I can tell you it sounds amazing. The roon app is mistakingly saying 176 but I have confirmed my files are being up sampled at 192 thru the Sonore app. We verified the sampling rate with Andrew on the line.
The Phantoms accept 176.4. Iâm doing it now.
Is there a mechanism over the optical link for the Dialog to talk to the Sonicorbiter and tell it what it wil accept? I didnât think there was. If there isnât how does the Sonicorbiter know what will be accepted?
In general, downsampling works best (i.e. best quality per CPU usage) when downsampling by an integer multiple. âAsynchronousâ downsampling is generally going to sound worse if implemented within the same performance envelope.
There are lots of technical shades of detail in sample rate conversation, and certainly some advanced techniques exist that accomplish non-integer rate conversions efficiently enough and without a significant quality compromise, but Roonâs down-samplers donât work that way. So, when downsampling for compatibility, we divide by 2,4,8,16,⊠and donât attempt the asynchronous conversion from 352.8 to 192k.
DSD formats are a multiple of 44100hz (DSD64 is 44100x64hz), so they get downsampled to 352.8, 176.4, 88.2, or 44.1.
The SonicOrbiter SEâs s/pdif port has a unique (and unfortunate, IMO) quirk: It only supports the following rates:
44.1, 48, 96, 192
This is extremely unusual in the world of audio productsâitâs customary to support rates in pairsâmeaning that a device that supports 96k should support 88.2k as well, and 192k support should imply 176.4k support. As I recall, this limitation comes from the iMX6 itself, since the S/PDIF interface used on the SonicOrbiter SE is built into the SoC.
The result youâre seeing is a result of combining of our âpower of 2â downsampling strategy and this deviceâs format support quirk.
Squeezelite is willing to take data from us at 176.4k (which is why it shows up that way in the signal chain view). Since we know that the s/pdif port doesnât support that rate, Squeezelite (or ALSA) must be performing a sample rate conversion. Iâm not sure what the ultimate output rate of that conversion would be, or the quality level of that resampling process. Personally, I trust ours more (since I know the implementation details!).
I like the fact that Sonore uses the same processor as the Dialog.
The iMX6 is very popular for products in this space because unlike many comparable ARM SoCâs itâs available in small volumes with modest entry costs at a tolerable price point. Looking a few feet to my right at the pile of gear we use for testing, there are at least half a dozen products that use that chipâitâs the current âdefaultâ choice, sort of like how most sub-$5k USB DACs use the same XMOS, FTDI, ESS Sabre, and Burr Brown components.
The âbestâ SoCâs (Snapdragon, Exynos, Tegra, âŠ) go to the cell phone and tablet manufacturers who measure sales volume in the millions, not high-end audio manufacturers who measure sales volume in the thousands.
The RPi2âs Broadcom SoC is definitely in a class below the iMX6 (but thatâs why CuBox starts at $89 and an RPi2 is $35âŠ).
Is there a mechanism over the optical link for the Dialog to talk to the Sonicorbiter and tell it what it wil accept?
No, s/pdif communication is one way. Itâs customary to handle capabilities manually on the software side (Roon has a âmax PCM rateâ setting in its settings screens for RAAT devices for this purpose).
Andrew mentioned to me that the closest conversion rate was 192 so that is why the Sonore product choses to upsample rather than downsample.
It does sound quite good. I mentioned to Andrew that it sounds better than his Roon Ready setting in the Sonore product. Especially on DSD256 files the difference in sound quality is huge.
You should get an RPi2/Digi+ for the Phantom to try it out. Pretty cheap and no up or down sampling upto 192 which is the max the Phantom will accept anyway. Since there is no rate conversion happening after Roon and before the Phantom, it will probably sound better.
Brian, why would you not have a setting within all Roon Ready devices that would let the user decide whether to upsample to the next available rate or let Roon handle. Could be a cool feature and eliminate some of these issues going forward with all the different DACs available. Just a thought.
I knew there had to be a hidden surprise with the little Cubox⊠Mineâs running fine connected through SPDIF to my F80, but I bet it is sneakily upsampling 88 > 96 as well.
Brian, why would you not have a setting within all Roon Ready devices that would let the user decide whether to upsample to the next available rate or let Roon handle
There are plenty of good reasons to have more flexible rate conversion options. I think one day we will.
Doing non-integer rate conversions in a way that meets our usual quality standards is not just a matter of adding a switch to the UI. Itâs a significantly harder signal processing problem. Thatâs why we donât have that switch today.
In an ideal world, the DSD would be up-sampled to a very high rate (28.224MHz or 56.448MHz), low-pass filtered in that domain, and then decimated to 192k without passing through 176.4k.
From our perspective, youâre choosing between two compromised options: Excessive downsampling to 44.1k using a very high-quality filtering method vs a multi-stage approach that under-shoots the desired rate than drags it back up to 192.
In the future, we hope to ofter the âidealâ path for situations like this.
Cool. No problems here. Sounds amazing as it is. Thanks for all you do for us audiophile junkies!