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.
- Setting up Roon server in a remote server.
- Audio hiccups during playing with mobile app. And limited sample rate on mobile app.
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.
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:
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:
where encoding can be:
AudioFormat.ENCODING_PCM_FLOAT → 32 bit floating point!
which accept a value up to 192000
WOW, surprise surprise, you can stream up to 32/192kHZ with Android without rewriting completly the app!
Is there a way to solve the streaming hiccups?
Will Bit perfect audio be implemented in the app in the near future?