The Sony ‘Gold brick’ definitely sounds better than the M17. If you’re after the ultimate in SQ, the Sony is peerless IMO. The only problem with the 1ZM2 is that it’s not Roon Ready, and probably never will be.
This is what makes the M17 so indispensable now, and at last I have a great sounding device that I can use with Roon in the home, and on-the-move outside.
Great! Thank you so much. Appreciate the effort to put in the details as well. That’s a shame, but I can see the logic why it wouldn’t work. I prefer the (fake) analogue method.
Shouldn’t be to hard to script up a setings intent to toggle modes when roonready is on.
Otherwise, give me a knob any day!
I agree not pocket worthy, plus you wouldn’t want to suffocate it and be swinging it around walking.
I ended up buying a super light weight pacsafe sling bag I just slip it in when I really want it but will be walking. Hardly notice it when weight is across body and movement is minimal relative to pocket. Room for a power bank to extend playing time and store whatever iems I am using. This is overkill
Modded a small 5v turbine fan for thermal regulation and because I am weird.
Also, recommend a Pelican Case for travelling. The 1040 is like it was made for it. Perfect when putting in luggage or whatever. I highly recommend that and silicon dust caps which you can buy for cheap. I only really use the 4.4mm balaced out and mostly 1 USB port.
Couple of extra points:
Also, not sure if they remedied the case yet, but button input was a bit difficult initially and they will send out free silicone strips to fix it once requested. I used one for the flap at the bottom of the case, as occasionally it would start to slip out. No problems now.
You can also use one of the USB ports to just power the stand fan. So buy you could use a 5cm or 10cm USB-C to USB-C cable instead of independent power.
I also switched out the stock stand fan for something quieter. Tried a few, but settled on one linked below which is about 30% quieter.
BAG:
https://pacsafe.com/collections/slings-waist-packs/products/vibe-150-anti-theft-sling-pack
TURBINE FANS:
https://www.aliexpress.com/item/32995460483.html
PELICAN 1040 CASE:
https://www.pelican.com/au/en/product/cases/micro/1040
DUST CAPS (something similar):
https://amzn.asia/d/gxVNxXo
REPLACEMENT STAND FAN:
https://amzn.asia/d/fbfeO3R
Thanks CG!
There are something’s in here that I haven’t tried, so will do that again.
I wonder how the signal transfer works internally then. I am guessing an internal network software loopback? Or possibly a virtual NIC?
Any noticeable difference in SQ using remote device or internal?
Not sure I get what you mean? Roon remote will see any Roon zones available on the network that the core sees. So it sees any other kit you have added as a Zone including the Fiio. All Roon Ready devices advertise themselves on the network and core sees them. The remotes connect to the core not the zone and core sends all the audio. Remote apps all have the ability to act as an audio zone to but you don’t want this active on the Fiio as it’s inferior to the Roon Ready output as it has all the Android limitations Roon built in to it. Can’t say I have heard any difference running the app as just a controller on the device.
My Android skills are very rusty - I went all Apple years ago and the two DAPs I bought recently are the first Android devices I’ve owned for a long time. How does one script a settings intent. Only thing I can find that might be what you’ve got in mind is monkeyrunner. Is that it? Honestly, I’m not sure I’m motivated enough to invest much energy in making the switch simpler.
Knob mode is a lousy tradeoff. I’m like you - give me a knob. But it means that I can’t use rooWatch, rooNuimo, rooDial, or Roon on the phone or Mac. What I’d really like is a hack for keeping the knob working while in button mode 
Thanks for the tip on the silicone strips. I’d seen that and wondered if they’d just come in the package - they didn’t. I’m not sure about this leather / metal case. I have a silicone case on order and arriving today. Going to look at that before I figure out whether or not to bother trying to get someone to send me the strips. If I stick with the leather case, I’ll want the strips … the air gap between the case and buttons isn’t great.
I don’t know if I actually have a use for the stand but I did fire it up and even on the lower setting, it’s too loud. I laughed at your recommendation for a replacement fan - Apple seems to have retrained me to think that what you buy is what you get. When I read that you swapped the fan I thought “Oh, right. It’s just an 80mm fan.” I’d definitely swap the fan if I ended up using the stand. Thanks.
It’s funny you say this. @CrystalGipsy already explained this isn’t how it works today. But I’ve been wondering about something related.
Roon Ready is a breakthrough. The difference between a Roon Ready and non-Roon Ready DAP is that the OEM took the Roon SDK and integrated it. In practice I think that will always mean some form of Roon Ready process on an Android device that integrates the SDK and exposes RAAT and whatever else. You get bit perfect, volume control, the right behavior for inputs/outputs, control release, etc. Without Roon Ready, and the direct participation of OEMs, it’s hard to imagine Roon or ARC ever being great on a device.
With these Roon Ready FiiO devices, we’ve got great Roon but lousy ARC. Currently any improvements to ARC have to come from the Roon team improving ARC across all Android devices (or internally special-casing specific devices).
@Oliver_Cassells mentions loopback and I’ve been wondering if that’s the approach that Roon could/should take to get ARC working well on devices like these.
If I were in the driver’s seat, I’d consider having the Roon Ready SDK / process support the on-device ARC app through loopback or some other inter-process strategy. Have ARC probe to see if there’s a Roon Ready process on the device. If it’s there. use it. If it’s not, do the lowest-common denominator thing it does today.
Until recently, I thought that the approach to a great ARC should be Roon lifting all boats by improving ARC. There’s still room there and they can certainly do a lot better. Now, though, running this device, the value of having the OEM integrate is very clear. The two-process Roon model works fine on the home network even though the Roon Remote and Roon Ready process don’t actually know about one another. But there’s no reason they can’t know about each other or that ARC and Roon Ready can’t also know about each other.
I can’t imagine the Roon guy folks haven’t considered this. I hope they do something like it - would just be fantastic to have ARC be as delightful as Roon on these devices.
[Decades of software/services development and leadership - I don’t know how to shut off the part of me that thinks it knows how everyone should design their stuff ]
Not sure they really need to anything with loopback I think they should just have an option to bypass the resampling and let what most other apps do on Android and pass on the native rate and let the device handle it. For the main app this is big change due to how much ofher stuff rides on the remote apps. ARC is new and should have been developed with portables more in mind and have more flexibility here. This would be the easiest option but their engine might be so convoluted that it’s not so simple. I remember Android on Roon before they refactored it a few years ago and decide to do fixed resampling on the core, it was a dogs dinner and never worked reliably. One thing this did was make it stable across all Android devices but with the obvious restrictions .
Streaming apps work on DAPs as they don’t do anything than pass the stream as is and because these Chinese DAPs tend to have system wide in SRC bypass it will be as source. A few apps out there still force their own resampling like ARC currently does, PlexAmp being one and I am sure PowerAmp did last time I tried it on my Hiby. As each dap has its own method of bypassing SRC and include lots of other stuff in the audio chain it may well be more problematic for RAAT. Hope not and we get ARC resample free and with local SD card support as without the latter even with SRC free it will be borked for offline use.
AT LAST I’ve found the settings in Android so that the M17’s LOCK button locks the buttons and screen, but keeps the volume wheel active.
I can now control Roon from my IPad Pro, lock the M17 but keep the volume control wheel active 
I wonder.
I dropped into this recently and didn’t go along on the journey. I recently went back and read the threads from the period you’re describing - helped me have more context for what you describe and I understand more of what you’ve been driving at.
I get what you’re saying about how ARC would improve just by passing the stream as is. Yes, please. I want that. I do think it’s interesting to consider what would be unlocked by having a participatory OEM play a role in ARC integration. Maybe nothing and ARC can hit end game on its own. But if there’s an advantage to something like “ARC Ready”, it seems that it would have to be delivered as a two-process solution where the OEM ships the device with something embedded (like FiiO Roon) and the Play store version of ARC discovers and collaborates with it. I’m on board with what you’re saying, though - anything like that is secondary to just getting the basics working.
Are you going to keep it a secret?
If any of you have battery management tricks, I’d love to hear them. I’m interested in anything related to Android settings or observations about anything else. Running the Roon Remote app seems to impact it more than expected. I’ve been playing with the 4.4mm out vs. the 3.5mm. The balanced out has an impact. Not sure if gain modes do. Just curious what you guys have learned.
I think thats asking a lot of the OEMs it’s why Roon Ready isn’t as prevalent as we would all want on these devices takes time and money their side to develop for it and the device needs the suitable resources available to run it all smoothly. I think they seemed more focused on ARC, they are adding to it all the time with the recent usb DAC update, CarPlay and Android Auto all in the early access part. Just hope it doesn’t loose momentum as the UI feature set and downloads need some serious work.
Remote app is a huge battery hog on iOS or Android always has been that’s why I don’t use it in the device so I get more battery life. I turned off the lights and keep it low brightness but thats about it. I do shut down Roon Ready when not using it as that will drain battery as it’s network active and does make a difference. Without it standby is stellar on the M11. Balanced and high gain are going to pull more juice overall to.
Yes, it does. I’m just using my Sony XBA-N3/MUC-M12SB1 combo via the 4.4mm jack and they sound great.
I am on board with what you are saying.
I guess I was hoping/thinking from my own developer perspective, that is a lazy implementation if so as there would be a needless set of data streams to and from both the roonReady and remotes that reside on the M17.
I know the RAAT will only go core and roonReady, but all auxillary status, metadata, images and user input is essentially sent twice.
for example, the on-board remote sends instructions to the core that in-turn sends the media stream + data to the M17 roonReady endPoint.
While also feeding the metadata and play state to the on board remote separetly. The operating state of on-roonReady end point communicates at intervals back to the core, that then gets also sent to the room remote app.
If the SDK is integrated, to have the ‘default output’ be that of the internal roonReady is incredibly straightforward.
I mean I know why it isn’t implemented. None of the parties involved make anything available. If it was open source none of this would be an issue, and it would all be at hand for FiiO to do it properly with Roon and Android codebases. Instead, all of them spend a whole lot of extra time and resources battling this and we end up with ad-hoc workaround like the FiiO developers, where the Roon development team have done next to nothing except provide APIs to companies who paid for the roonReady cert.
It’s all systemic and I strongly believe in the open source ethos and that doesn’t mean you give everything away. But without some common sense they all end up being inefficient regardless. It is a limit of company protocols, unwillingness to take the most common sense approach and refuse to budge for fear of it being taken for free, but if you are doing your job properly then you maintain a customer base, and can even increase it because obstacles to integration are removed, and can instead spend those resources on innovation and evolution.
The whole aspect of how hard Android make it hard for developers to bypass the OS audio driver because of ‘things’ is a prime example of this. I know for a fact it is incredibly easy for them to remove this restriction, but don’t because they want control.
If that ideal world existed bitperfect Roon would have been on these devices a gen ago.
End rant
One could argue that the OEM is already implementing to an interface/spec/whatever for Roon Ready and that ARC could theoretically just be made to transparently leverage that work. In other words, the OEM wouldn’t necessarily have to do double the work to support Roon and ARC. You’re right, though, that any way you slice it, it’s just more work for the OEMs - even just validating that ARC behaves as expected would be work. Likely a lousy idea. Wasn’t my first lousy idea, won’t be my last.
Have to love headphone cables that cost almost as much as the headphones themselves!
Yeah, it was the only way I could get them to run balanced with my Sony Z1! 
If you are using the DSD mode on Enhanced gain mode, you will definitely want the stand.
When it gets really hot, you can start to hear noise and crackles, I had one freeze early on to.
Regarding scripts, that is a long long answer the low level approach I am taking. But I am sure with Tasker that can easily be done without the need for rooting the device or anything. Tasker is an amazing project, and if I can reasonably get away with using it without sacrificing to many inefficient call traces or scheduling, then it’s my go to.
I would wager a bet using it would be able to extend battery life and improve resource utilisation of enough time was spent setting up well thoughtout projects and consideration of all use cases.
My thoughts on ARC are… They wasted their time. It was a commercial decision in my eyes.
I feel it is really meant for a different market then most audiophile and traditional users.
I feel it’s those who want it on their phone, not fussed about SQ or technical DSP aspects, but connect their AirPods and want access to their home library and streaming.
I’m not sure I’m completely following your architectural proposal but I think I am. It’s fun to talk about but we’re just an echo chamber and we can’t do much better than talk about what we’d build in a green-fields scenario. Roon doesn’t have green fields - they have tech, customers, pressing needs besides re-architecting.
That said, if I were starting this project from scratch, with all of the learnings and hindsight of the moment, I’d do something like:
I’d make #2 a faceless service that requires the Roon Remote app to work. In collaboration, they’d do the sensible thing with respect to transport, metadata, volume, buttons, etc. I’d make #2 as thin as possible - possibly not even putting RAAT in it though there might be I/O or buffering advantages to doing so. Keeping it thin would help with serviceability and versioning.
#1 would be a controller for #2 when #2 is present. It would also have a best-effort implementation of #2 built in to work on devices where the OEM hasn’t integrated.
But all of this isn’t very meaningful other than being a fun, intellectual exercise. Nobody is asking for our opinion and we’re not juggling the complicated legacy issues that they are