Roon 2.0, build 1259
Linux based server / OSX remote
Intel Core I5/8400
64GB RAM (50+ available)
Tiered storage (cold 300MB/s+, hot 1000MB/s+)
Neither CPU nor storage is stressed
Networking Gear & Setup Details
Gigabit Ethernet >Cable> Unmanaged Cisco Gigabit Switch >Cable> Fritzbox
No problems with Network / Internet Connectivity
Description of Issue
Roon sometimes skips tracks or gives up at all when the WIFI connection is unstable or when access points are doing an handover.
Add an option to allow the Roon SW (endpoint/client) to cache/buffer more or allow to make this cache bigger. Maybe define X-MB as a Cache and buffer an entire track when the track size < buffer.
Karsten
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
2
Are the endpoints connected via Wi-Fi, or the core, or both?
Your first step should be resolving the poor Wi-Fi connectivity, or use Ethernet.
Regarding your suggestion, where is the buffer meant to be? If it’s in the core, how will this help? Moreover, it is my understanding that the DAC controls timing, and if this connects to the core over Wi-Fi, increasing the buffer isn’t going to help much.
If you want assistance diagnosing your Wi-Fi connectivity issue, please provide more details of your setup including network devices, core, endpoints etc., and how they are connected.
No, not a at all. For highres I am using cables and my Wifi does in general do a decent job. It most often happens when I run the Roon SW on an iPad or iPhone. So in other words I am using the Roon SW itself as a client. Correct me if I am wrong but the server somehow has a bit pipeline to the Roon SW Client and the SW then passes the audio to an inbuild audio of the iPad/iPhone. I was thinking about having some kind of a cache or buffer in the Roon SW (as an endpoint / client).
So the Roon server then transmits the data, the Roon SW caches and forwards it to local audio device.
Not a priority but sometimes a little bit annoying. It’s an enhancement request, case can be closed.
And it does not always happen, it sometimes happens when WIFI isn’t perfect (in our kitchen) or if I am in the middle of 2 APs and the handover takes a little too much time.
In some streamers you can choose the buffer but I never tested with roon to the same device, device that when used with roon is just a bridge and your core becomes the streamer. I guess this is one of the reasons that wifi is not recommended
Gotcha, there is definitely use cases for that. For example when doing indoor cycling we are using an iPad for Zwift (training app) while we are using Roon on the same iPad as an endpoint. You can now of course get another wired roon endpoint but it is not very convenient. Or when we are cooking we are sometimes just carrying an iPhone or iPad to the kitchen and we are using it as a remote and endpoint. In these cases ease of use matters more than quality (and it is typically not an endgame DSD, DSF or 96khz FLAC). Even that should not be a problem as our Wifi does 50 Mbytes/Sec+ (500-800 Mbits). And to be honest internet streaming services like Spotify or Qobuz can get this done on our Wifi.
My conclusion, ya I am using Roon primarily for highres, ya it’s then always fully wired but Roon is also great to get some music to Airplay or Roon SW endpoints. So Roon is great but it is maybe an opportunity to make it even better. My partner for example almost always uses the Roon SW as a target and that almost always over WIFI.
mjw
(Here I am with a brain the size of a planet and they ask me to pick up a piece of paper. Call that job satisfaction? I don't.)
7
Do you mean the iPhone or iPad are the streamer / audio device? If it is for control only, the audio stream doesn’t touch iOS; the signal goes from the server direct to the streamer. Nonetheless, your Wi-Fi should handle hi-res anyway. I happily stream hi-res to a Chord Poly and Bluesound Pulse.
If you use the ARC app in the home over Wi-Fi, it will buffer because there are no timing issues associated with streaming the same music to multiple endpoints. You could try this as a workaround.
