I was very pleasantly surprised when the iPhone was added as a controller.
Unfortunately, that opened another idea. Whilst waking up this morning, was just thinking how great it would be if my iPhone could also be an “end point” playback device.
I would like this too. I have an old iPad attached to powered speakers that I use for Tidal playback in my kitchen. Roon 1.1 does not show it as an AirPlay device (have not tried 1.2 yet), so I’d love to have Roon Bridge for it.
Hah. I only wrote that stuff because I know Anders is technical enough.
The less ridiculous version:
If we turned on playback on iOS right now, there would be clicks and pops and dropouts and sound quality issues.
We have a solution to this problem, and we use that solution on the other four platforms, but Apple won’t let us release it because of App store rules.
The root cause is an interaction between audio playback and the technology that allows us to deploy Roon across five platforms without doing five times as much work. This is a technology that we depend on for strategic reasons, not something we can migrate away from.
The people who make that technology are working on the problem. Once their fix is available, we can incorporate their latest code and see if it fixes Roon. It’s a complicated change for them, and they are an established team with lots of customers that depend on them to build stable infrastructure, so their pace is not super fast, but they are working on it.
There is no .net version of RAAT. It’s C/C++ on all platforms. Porting it to iOS is easy. The problem is packaging it up in a way that makes a good user experience.
iOS apps get suspended when they go into the background. Apps that are playing music right now are allowed to be running in the background, but they get suspended when the music stops.
So think about the user experience: your zone would only be visible when:
The app hosting the RAAT zone is in the foreground
OR Music is playing
There are two places we could put RAAT
Inside of RoonRemote
Outside of RoonRemote in a separate RoonBridge app
If we put it outside of RoonRemote, then as soon as you switch to RoonRemote, the zone disappears because the RoonBridge app gets suspended. That’s no good, because then you can’t reliably pick music for the RAAT zone from the phone itself.
All you could really do with an iOS RoonBridge app is park it in a dock, leave the RoonBridge app on the screen and control it from elsewhere. Neat, but not that interesting. The really bad thing about that app is that people who are looking for the “control + playback on the phone” experience will be able to get themselves into really confusing situations trying to use RoonRemote + RoonBridge at the same time since their zones will be getting suspended at inconvenient times by iOS.
If we put it inside RoonRemote, we get clicks + pops because the .NET runtime mucks around with the audio playback.
On all other platforms, we separate the RAAT code from the heavyweight Roon process–this is what RAATServer is on win/mac/linux. On Android we run RAATServer as a service and isolate it to a second process so the .NET stuff doesn’t impact it.
On iOS, rules are rules. I know that we are better listeners than Apple, but that doesn’t mean that we are necessarily in a position to fix or work around their platform decisions. I know it’s frustrating–it is for us too. I wish we could just release this thing and stop discussing it.
Because we use the same code for each platform, most of it is C# or other .NET languages, and Mono/Xamarin is the only mature way to run that code on non-windows platforms.
Tidal and Spotify allows streaming to BT speakers from iPhone/iPad therefore what is it they do that you guys are not doing that makes it work? I am just wondering if you could emulate their functionality on iOS devices.
Once the bugs have been shake out of the Mono/Xamarin software libraries that the Roon application is dependent on, it too will be able stream to iOS devices.
The development of Xamarin is not controled by the Roon devs, however, I believe there is activity by the Xamarin team to resolve this.