Yeah, what I’m doing is much more on the tinkering end (trying to get site-to-site VPN working so that I can have a single core serving two homes and a remote that doesn’t care which home its in). A by-product is that I can use the remote out-of-home as well as ARC, or that I can use ARC without port-forwarding. But I would never recommend it as a way of engineering what @MamaTried wants, which I want too - the seamless passing of whatever I’m listening to from my remote solution (ARC) to my inside solution (Roon). Neither Apple nor Spotify nor Alexa/Amazon have gotten anywhere close, though Spotify arguably is closest to enabling it - and I’ll place my $ on them over Roon or god forbit, Roon tinkering.
1 Like
I’m not sure if I should give in and buy one of these or if I should stop following this thread to make it easier not to buy one. Seems so close to, if not exactly, what I want.
1 Like
Maybe hypothetically - If you had this working well on a DAP, why would you ever run ARC? I’m sure we all have knowledge or theories about why the Roon folks introduced ARC as an app instead of as a feature. What you’re doing bridges the gap. If you got it working really well, what would be the point of running ARC?
[This might be truly hypothetical - at least for the case where you’re on a mobile network trying to use a phone as a hotspot.]
Use your phone. If you find you’re wearing down your phone, invest.
My geek equivalent of dog → kids
1 Like
Around the house, I use a Mojo 2 + Poly. When it works, it’s enjoyable. When it doesn’t, it’s frustrating. Disconnects, skipped tracks.
1 Like
I think “well” is doing a lot of work here. I’m not counting my chickens - VPNs can be fragile and finicky, and despite our best efforts and the quality of prosumer gear, sometimes require visits to remote locations to pick up the pieces after we inadvertently screw something up. My feeling is that ARC is going to be a form of KISS. For now I’m experimenting and we’ll see where it goes.
I like solutions that just work. If I could get a single DAP unit that had the front-end of an iPhone / ran ARC iOS and had a good DAC, man I’d be psyched. But right now, the appeal of being able to use my phone while on the run and not have cables attached to it wins. So I’m using a bluetooth DAC/amp (Fiio BTR3k) and an iPhone running ARC. Sacrificing audio quality for “it just works like I want it to”. And at my desk(s)/bedside I have big set-ups, and in each home I have both Sonos and RAAT 2-channels. It’s a lot of audio engineering. I’m betting on ARC eventually being easier than “remote enabled Roon remote”, or maybe “ARC + Roon remote converge”. But I’ll keep my options open
Listening to a great album called The Deer’s Cry by The Sixteen on a Sonos ARC (get it?) while I work in the sun.
I read a lot of words, and then you said something about the sun, and I got confused.
What you say makes sense (aside from that thing about the sun). Mojo 2 + Poly is a bit large for mobile but that’s not a dealbreaker since I like backpacks and I’ve typically got one with at least a MacBook in it.
The Mojo 2 / Poly setup would actually be really, really decent if it:
- Had a WiFi implementation that actually worked
- Had a physical switch that toggled between WiFi client (Roon Zone) and Bluetooth receiver (Arc on an iPhone → Poly over Bluetooth).
That would be a pretty decent setup.
Sounds interesting. I have added it to my play queue…
I’m playing with an iBasso DX320.
Can one of you with more experience with DAPs help me understand if the signal path shown below is what I should be seeing?
I had some initial funky behavior but firmware updates and a reboot seems to have led the device to stabilize at this sort of signal path in both Roon Remote and ARC.
Everything is upsampled to 768/24.
There are no DSP settings enabled.
Is this Roon upsampling to avoid allowing AAudio to do it?
This device has a bit of a learning curve - a chunk of that is me not having used Android for a few years. I’m trying to come to any conclusions until I have it dialed in.
Thanks!
You get a better sample rate than I do. But otherwise my path looks identical.
It is doing those conversions to play at a bit depth and sample rate your DAP/underlying OS can understand.
My hope is, Roon will eventually get their software to pass native rates to our systems. That will require a deep dive into how android passes everything in and out. Doable, but usually with a larger development team.
Thanks. There’s more going on here and I think there’s a bug. At least with the iBasso DAP I’m using.
Here’s what I see.
Test 1. Restart. Run Roon Remote. Play a 44/16 track. Track is converted to 768/24 by the core, sent via RAAT, pushed to AAudio in 768/24.
Test 2. Restart. Run Qobuz. Play a 44/16 track. Track plays in 44/16 as expected. Pause playback. Switch to Roon Remote. Play a 44/16 track. No conversion on the core. Track is sent at 44/16 via RAAT and sent to AAudio in 44/16.
Test 3. Restart. Run Qobuz. Play a 44/24 track. Track plays in 44/24 as expected. Pause playback. Switch to Roon Remote. Play a 44/16 track. Track plays in 44/16. Play a 44/24 track. Track plays in 44/24.
Test 4. Restart. Run Qobuz. Play a 44/16 track. Track plays in 44/16 as expected. Pause Playback. Switch to Roon Remote. Play a 96/24 track. Track is converted down to 44/24.
ARC obviously moves all conversion to the device but the behaviors are all effectively the same.
It looks to me that Roon Remote is not correctly determining the sample frequencies supported by the device. After a reboot, and if the only clients you use are Roon clients, everything is going to play at 768 in my case and possibly the highest supported frequency in your case. But if a better-behaving client, like Qobuz, plays something, that results in Roon thinking that the only(?) supported frequency is whatever the previous client played at. And Roon will up or down sample to that.
I hope they can fix this. I’ll report it as a bug but probably not today.
I believe what is happening (totally a guess) is that Roon is querying the DAC for its bit-depth. Using Qobuz, which understands how to change the bit-depth, changes the DAC to the appropriate bit-rate and Roon then sees that as what to use (sort of).
IMO, the biggest issue is Roon not telling the DAC what to use based on the track, but instead upsampling/downsampling to whatever the DAC is currently reporting.
2 Likes
I think that’s pretty much what I said
Do you see the same behavior on your DX300? I’m curious if the behavior is specific to the ROHM DAC I the DX320.
Standard for some DAPs but it’s dependant on how they tweak the Android OS to get the bypass from system resampling. The DAC is being left in a certain state by other apps. As Roon currently doesn’t change the freq for Android it will get what the last freq was from the os and assumes this is the fixed rate it works at and will resample to this. It will vary according to whatever rate it gets back from Android which in itself seems to vary on certain DAPs dependant on what app was used prior and what rate it’s been left in. Other daps like my hiby are always 44.1 regardless, some Fiios seem to vary all the time. Same will occur on ARC until they sort this out for inbuilt DACS. Don’t expect Roon app to ever work as they don’t seem to be focused on getting Android Audio working but perfect on anything other than ARC.
Thanks for the explanation. I gather this means that I’m, as they say, pounding sand if I post a bug report but that’s probably not going to slow me down.
I prefer using Roon Remote to ARQ on my local network. I like features like DSP and direct access to Tidal and Qobuz. The issue I’m hitting is that when the core samples up to 768 and then tries to stream via RAAT, it’s never stable. I don’t need this explained - the nature of RAAT and the increased size of the bitstream isn’t reliable.
So what I’m finding myself doing is flipping to Qobuz, using some track there to get the DAC at some other frequency like 44 or 96 and then flipping back to Roon.
I think I’m just going to make a few short tracks at various frequencies and then throw them directly onto the DAP. Then I can just pop into iBasso’s player (Mango) and use them to manually set the freq. It’s not perfect but at least it’s a workaround.
Thanks again for the clarification. It’s clear that Roon folks can fix this if they want - hopefully they can look at it when the dust settles on some of the near-term higher priority stuff.
I made a collection of 1-second flac files at frequencies ranging from 44.1kHz to 384kHz. I threw them onto my DAP. This all works as expected now - I can play them in the DAP’s native player (Mango Player in the case of iBasso) and anything subsequently played in Roon Remote or Roon ARC plays at that frequency.
If anyone wants to play with these, I can DM you a link to grab them from a Google Drive.
1 Like
Looks like FiiO has just released Roon ready firmware for M11s
Hope this is legit, as I see no mention of FiiO being an official Roon partner.
1 Like
My DAP had similar in their release notes. Roon doesn’t have it listed.
I think the partnerships are far more involved.
My Shanling isn’t Roon Tested or Roon Ready.
It works fantastic.
Fingers crossed for you and others with that device.
I’ve held off buying. Awaiting official announcement from Roon. Did pick up a Shanling H7 though which I’m thoroughly enjoying with Roon ARC on the go.
1 Like
With the Shanling “Roon Ready” firmware, do Roon and ARC play tracks at their native rate or do they sample up or down to whatever rate the DAC is at when the Roon/ARC app is launched?
If I don’t do anything to change it, Roon/ARC read my iBasso at 768. Roon can’t consistenly maintain a WiFi connection at that rate.
I’m now in the habit of pinning it to 96kHz before I launch Roon or ARC. I’ve got it set up so that it’s easy to do that but it sure would be nice to not have to think about it. I think the ball is in Roon’s court on this and that it’s not a DAP-specific thing. I’m just curious, though, if Shanling somehow addressed it in their firmware updates.