Roon in a remote Server / Android HI-RES Streaming / iBasso Streaming Hiccups

Support
1

Hi everyone,
I’m a long time user of Logitech Media Server and I wanted to try Roon. So I bought the monthly subscription just to play around with the software before buying the lifetime subscription.

Until now I have a love/hate relationship with Roon. I am audiophile, so I love all the UI the DSP and the metadata stuff, but I’m also a software developer, so I hate how certain functionalities are so badly written.

The problems:

  1. Setting up Roon server in a remote server.
  2. Audio hiccups during playing with mobile app. And limited sample rate on mobile app.

Problem 1

I read a lot of solution about this problem in the Thinkering forum session. Long story short: I installed in my local server which is in my local LAN.

During the debugging session I, with another friend (software engineer), have analyzed with tcpdump the network behaviour of Roon. He literally told me “the network stack of this software is just BS”, and I agreed.
You simply cannot rely totally on broadcast packets to reach the clients. It’s just a bad practice. Because, not only you’ll have a really bad time using a VPN with RoonServer on another PC outside your lan. But It can cause problem also in you own lan if you have more subnet and in general with a more complex network setup.
Of course, Logitech Media server doesn’t suffer of this problem.
Using only broadcast packets, using a metaphor is like finding a 40 year old parachute backpack in your garage from your grandparent and you decide to jump from an helicopter. The parachute may open, on maybe not. Network discovery is a good tool to simplify connections, but IT MUST NOT BE the only one.

Problem 2

Testing hardware for Roon:

  • Server: Xeon 28 core, 64gb ddr4 quad channel RAM, wired gigabit link

  • Client: iBasso DX160 DAP, connected with wi-fi, average wifi speed 50Mbit/s, stable.

I compared the performance with LMS installed on my remote server in another country with less stable and slower connection (it is not in lan and I must use it with a VPN)

Source file and DSP path:

LMS: Source file 16/44 → 64bit 192kHz → Apply headroom → Apply convolution → 24bit 192kHz → iBasso
Roon: Source file 16/44 → 64bit/44.1 → Headroom → Convolution → 24/44.1 → iBasso

Now, Roon has 2 bit advantages:

  • It’s in LAN
  • It outputs a way smaller file due to some bad development decision (see later)

Despite that I had ZERO hiccups or problems or interructions with LMS and with Roon I could not even listen to more than 10 seconds of songs without interruptions.

I really should mention that LMS is free and written 14 years ago with a such bad and low performance language like Perl. Roon is 700$ and written in C#.

About sample rate limitation in Mobile APP:
I was sincerely hoping that, as a pricey audiophile software I COULD AT LEAST use the app with direct DAC access. The best choice if you write an app that needs bitperfect audio is to just write it in native language, with Java, especially from Android 5 and more from Android 8 is really easy to stream bit perfect music to an internal dac, at any sample rate.

But you used Xamarin, which is perfectly ok, maybe not the best but by far not the worst.

To achieve bit perfect play Xamarin exposes some low level audio api.
You can use AudioTrack for the playback:
AudioTrack class

Which has this kind of constructor:
AudioTrack(AudioAttributes, AudioFormat, Int32, AudioTrackMode, Int32)

Where AudioFormat is an object which support various methods some of them are:
setEncoding(int encoding)
where encoding can be:
AudioFormat.ENCODING_PCM_FLOAT → 32 bit floating point!

Or
setSampleRate(int sampleRate)
which accept a value up to 192000

WOW, surprise surprise, you can stream up to 32/192kHZ with Android without rewriting completly the app!

My questions:
Is there a way to solve the streaming hiccups?
Will Bit perfect audio be implemented in the app in the near future?

6 Likes
2

I don’t understand the tech talk, but I believe it might help if Roon listened to some software veterans/subscribers to solve the recurrent problems of streaming hiccups.

3 Likes
3

I’m reminded of the Russian (apocryphal?) proverb, “It’s not how well the bear dances, it’s that the bear dances at all.”

Anyway, not sure how you are supposed to implement #1 without broadcast packets. JRiver solves it by generating a unique key for its server that it displays to you that you then write down on a post-it note and stick on the side of your client. The server then pings a JRiver internet server to advertise its local IP address and its generated key. Then you go to your client and consult your yellow post-it note to type in the magic key, which the client uses to query the JRiver internet server to get the matching local IP.

What could possibly go wrong? Let me tell you. Or not. You can probably figure it out.

Conversely, Roon raat sends out an ollie ollie in free on your lan, your servers and endpoints respond here! and connection is reliable and almost instantaneous. I have not used a packet analyzer to discover how many milliseconds it actually takes. Haven’t needed to, because it just works. Every time. Reliably. Unless the server or network is down.

So how does LMS do that? DLNA multicast? Squeeze UDP? Honest question. I don’t know. I only played around with LMS for a couple days and concluded that life’s to short for all the tinkering required for a sub-par music listening experience.

Not sure about the other observations.

Sorry if my response comes across as harsh or dismissive. Roon has its issues, just like any software. Trying to use it over VPN from another country, however, seems like a stretch, as does comparing LMS to the overall roon experience, albeit limited to your LAN and a good internet connection.

Regardless, I’ve tried them all, and roon is the worst except for all the others.

3 Likes
4

It is not about implement the connection WITHOUT broadcast packets.
It is about not relying on ONLY broadacast packets.

“it just works. Every time. Reliably” Yes! But only if you have only one subnet in local lan. I think here is well explained why it can’t just work for everyone: How I got Roon working over OpenVPN (hard for me, easy for you) - #7 by ogs

A simple and improvised way to connect without broadcast packets as a dialog:

  • Client (knowing the server IP): "Hello server, I’m online! "
  • Server: “Hey! Nice, what is yout current audio interface capabilities?”
  • Client: “I can stream up to 32/384, but sadly no MQA”
  • Server: “Noted, when a song start I will contact you. From time to time don’t you mind if I ping you just to check you’re alive?”
  • Client: “Sure! No problem. Anyway If I’ll ever disconnect I’ll send a message to you.”

Now, despite the funny part. In some network configuration broadcast messages just can’t work. The user must have the ability to tell the client “Hey, the Roon server is at this IP address, do your thing and let me play music”. Implementing a well-behaving client-server communication is just basic networking knowledge.

This still does not solve the streaming issues. Even if Roon streams in uncompressed WAV, a 24/44.1 file has a bitrate of ~ 2Mbit/s. With a 50Mbit/s bandwidth I should be able to stream at least 20 of them AT THE SAME TIME!

Of course that if I plug the ethernet cable with a gigabit connection everything works.
But still the issue remains, I don’t know if it’s a mobile app problem, a networking problem of a mix of both.

To me having the server in a datacenter don’t seems to be a stretch at all! I can listen to my library at home, in my car, when I’m at friends home and using all my DSP profiles for my headphones. This is indeed the main advantage of a client-server architecture. And my compairson with LMS isn’t a strech either. I didn’t compare the overall experience, but just the plain networking stack which is the HEART of a software with a client-server architecture.

5

Aye, there’s the rub.

I think (don’t remember for sure?) that you can use fixed IP addresses for your server and clients in roon?

6

I have not had any dropouts, stuttering, etc. with any local or streaming from Qobuz or Tidal at any resolution on my lan/internet setup. I’ve seen a lot of other folks reporting problems, so maybe I’m an exception?

7

So how does LMS do it?

8

I know. But for the first connection from the client to the server.
This happens by clicking “help” while connecting and typing the server address.
But, when you want to configure the audio output (or if you go in Settings->Setup->Configure Roon Core), the same “Trying to connect to Roon Core” appears, for whatever reason (Hey, I told you before that the Core is at that IP), but without the ability to specify the IP addr.

I’m really happy that you are enjoying you Roon stability (and a bit envious too!) but don’t generalize; from what I’ve seen I’m not the only one reporting problems, sadly :frowning:

1 Like
9

It uses Slimproto protocol. Which works with broadcast packets but can work even without using them.
The communication is very similar to the one I’ve written before. For more info: SlimProtoDeveloperGuide - SqueezeboxWiki

10

Roon isn’t designed for use via a VPN and makes no promises about it.

Do you get dropouts if you use Roon as intended ? If so, then Support can assist.

1 Like
11

Your analysis was wrong. We only use multicast/broadcast for discovery. mDNS and SSDP do the same. It’s very common. The communication protocols are all TCP, no broadcast or multicast there.

It is well known you can you can not do this. Android implementations almost universally resample to 48khz. This is not news. Only UAPP solves this by bypassing the audio stack. You clearly are reading docs and not actually writing any code or testing any output.

Again, you are assuming incorrectly. Our audio code on most of these platforms is actually written in C, and we are bitperfect on every platform where we can be (without going the extra step that only UAPP does).

On iOS, where the audio stack does not get in the way, we have users doing 768khz out of Roon to Chord Dave and also bit perfect MQA works fine. Android is just bad, and I say that being a life long Android user.

Listen, you clearly know stuff, but you also have a pretty shallow understanding of Roon. If you actually want to solve your issue instead of just ranting, work with @support by describing your actual setup. You did an ok job of talking about some of your hardware, but not the network topology/hardware or the storage.

Comparing to LMS or any other software is not interesting or valuable. It’s apples and oranges. Focus on the details of what’s not working and what those symptoms look like. There are hundreds of thousands of people running Roon just fine, and many came over from LMS. It can work, but it might take some patience to figure out what’s happening.

4 Likes
12

I may not have been clear. My analysis was not wrong, to me it is pretty obvious that the communication protocols are all actually in TCP and the discovery steps are the problem. I can’t just open a roon client, set the server IP and make it work, which should be a trivial thing.

Oh yes only UAPP
and Pulsar
and BlackPlayer
and Neutron
and SBPlayer
and HibyMusic
(all of these ones tested personally)

But hey, maybe Google was just having fun writing libraries that let you think you can play hi-res file but you actually cannot do it.

Even easier than!

If a software is open source and there’s a problem: I’ll write the code to help you
If a software is cheap and there’s a problem: I’ll send a feedback to devs
If a software is expensive and there’s a problem: I’ll send a feeback with a deserved rant.

I can really write to support describing all my network topology. But are we really sure that I won’t have an 8 words answer like “Roon is meant to work only on LAN”?

And for the drop-out I have them with Roon setup as intended in a single subnet.
Topology of the storage on the home server: RAID10 of 4 15k rpm 2.5 HDD with nvme write and read cache. Home network where Roon works: server wired to the router. Router is a Netgear NightHawk R7000. The client as I wrote is an iBasso DAP, a file transfer from the home server reach a steady speed of 6MBytes/s, which are plenty enough for the streaming of a 24/44.1.

3 Likes
13

@Simone_Filippini, looking through your posts I am drawn to two things that jump out for your ssues with playback . First the R7000 and 8000 are routers that’s WiFi implementation has seemed to have caused issues with Roon in the past and continues to do so. I had R7000 and nothing but trouble with it with Android clients. You could try turning off IGMP proxying if it’s not already as this can help. I ditched mine in the end for Ubiquiti wireless and all my issues went away. Not saying you should have to do this just giving my experience with same hardware. Why this was the case I don’t know and it’s annoying to have to change kit to get software to work.

The iBasso dx160 is also known to have issues with playback with Roon quite a few threads have brought this up and you can read about other WiFi issues with it on Headfi. It does not have the best WiFi implementation and has a pretty low spec cpu. I had one for a week before sending it back it was that bad, UI sluggish and WiFi was dreadful and not just for Roon. It would not get past 15mb/s directly under the ap and was about 5mb/s away. Whilst that should play hires audio it did not consistently and via Roon it stopped and started all the time so I believe there is something else that the device doesn’t like about Roons software maybe just too taxing for it. I changed it got a Hiby R5 and never a drop since.

I have 9 Roon zones and none have any playback issues only the DX160 of any endpoint I have tried had an issue and I have many other androids devices that work fine, SRC aside.

I agree with you that Roon should be able to play hires content on DAPs that at least bypass SRC at an OS level like DAPs. There are more apps that do it than UAPP but I would not count SB Player in that category as its not bit perfect as you fix it’s output so its always up or down sample. Why dont you connect this to Roon as it wil play to Squeezbox endpoints to. It will get you upsampled content as it does from LMS works when I have tried it.

@danny as mentioned there are a few apps that manage to bypass SRC, UAPP is the best and most reliable I agree. Hiby iBasso and Fiio all manage to allow app that don’t internally resample, play native bit perfect rates. BubbleUpNP, Tidal and Qobuz apps are just regular app store versions on Hiby and they allow SRC on regular mobile platforms and avoid it on the modified DAP platforms. Why can’t Roon do this instead of forcing resampling? What are they doing in their native Android apps that Roon can’t or isn’t. There are a lot of DAP users that would love to use Roon and get the full potential from our devices but they are held back to what Roon decides.

14

Hi CrystalGipsy, first of all thanks for your suggestions!

I already tried turning off IGMP proxying with no result. I don’t think it’s a router fault, with my iPad or smartphone (android) I can easily get around 600Mbit/s of speed with 5Ghz.

I think that there’s something wrong about iBasso players and Roon, as you know I can reach a stable 50Mbit/s connection (which is way far of 600Mbit/s I can get with the smartphone) but it should be more than enough.
I can suppose it’s something about the RockChip cpu that has some problems maybe with the mono framework used by the Roon App (maybe some missing CPU instruction?) I don’t really know.

I counted SB Player not because it’s bitperfect, for ex. I resample everything to 24/192 when I stream to my DAP. But it can bypass android resampling at 48kHz.
Android resampling is a problem if you rely on OpenGS EL to stream audio, but with AudioTrack or even the newer AAudio (I think from Oreo) you can avoid android resampling. Which is demonstrated but a good moltitude of app (let’s not count UAPP in them, the dev has written a custom audio driver)
Qobuz won’t resample anything too for example!

I’ll try debugging the behaviour of the iBasso DAP trying to understand why it can’t stream properly, maybe I’ll find a solution. It seems that DX220 also has this kind of problems. Does DX300 have hiccups too if you know? It is based on a different platform with different CPU.

If I won’t find a solution I think that Roon can stream to Squeezelite - like devices too. So I can use SBPlayer (I guess?) and see how it goes.

Thanks again,
Simone

15

Well, it appears that with SBPlayer you can get stable high-res streaming without any hiccups on the iBasso DX160

400084400919_509591
400084400919_509591720×1280 53.4 KB

16

And here we go.
Remote Roon server ina datacenter playing with a local client. Aaaaaand … you Just Need to use a Squeezelite client

Screenshot_20210430-145825_Roon
Screenshot_20210430-145825_Roon1080×2340 225 KB

It seems that at the end of the day the good old LMS (with its slimproto based networking) Is fixing the problems (and flaws) of Roon:

1- High res streaming on Android.
2- Hiccups on iBasso streaming.
3- Using a remote server.

1 Like
17

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.