SimoneF

Hi, I appreciate your support! I stopped developing new versions since it was really stable, and also because I lost all the sources after my laptopt broke. I will consider taking up the project again during this year (no ETA) mostly to update all the drivers needed for the most recent hardware. On the squeezelite side there aren't really any new updates.

I've written a quick guide about how to access Roon from remote (not from your home LAN network), how to auto start Roon without having to login on Windows. Maybe it can be helpful for someone.. Roon: remote access, auto-start without login with mounted samba share on Windows

Not a very mature platform yet

I don't know, I use it in a Windows VM which is up since the start of June and RAM and CPU usage are very normal (aka extremely low unless it's scanning for new files)

No. As you can see from the pic even ROCK uses mono. To avoid random CPU spikes: 1- Use Windows 2- Use a Windows VM in your Linux host.

I agree for different reason, multiroom and Qobuz and Tidal integration is already present on LMS, for free (and I find the Slimproto protocol to be way more flexible and efficient than RAAT). How's the Roon radios works and the DSP is what led me to spend 700$ for it.

First of all, about the problem of memory usage and cpu spikes with large libraries: Roon is written in C# and so it uses the Microsoft .NET framework. To make is work on linux and macOS they use mono which is an open-source VM to let users run .NET software on OS different than Windows. Probably all these kind of issues and not due to Roon itself but on mono (which, as a dev myself, I would not ever use in production). If you want the best performance and stability just set up a Windows VM and probably you will solve all your problems. My experience with the Roon support is indeed pretty good, they have always helped me when I had a problem. About feature requests they are just bad. While I understand that they do not take seriously a request such as "when Roon is doing something in background the sound is worse" without any kind of data in support of this theory (I wouldn't take it seriously either) other problem such as: - Android app not bypassing android mixer and limited to 16/48 - Frequent freezes of iOS/iPadOS app - It's "impossible" to run Roon core outside your LAN because clients discovery is made only with broadcast packets and you don't have the option to do an incredibly stupid thing like being able to specify the server IPAddress - You cannot disable automatic discovery of new audio files. This cause Roon to wake up hard disks every 5 second and so hdd cannot go in sleep mode. This is just plain stupid and can reduce HDD lifespan drastically. (let's not talk about power draw) Are just ignored by Roon's dev team, which is shameful. Still I will continue to use it since there isn't anything like Roon on the market, and I've tried pretty much all the "audiophile" players

Well if you don't get such a simple evidence probably yes. But that's enough, time to add a new member in the ignore list 🥳

As I already said this question can be -Very naive -Very rethorical In both cases, a waste of time.

I mean you haven't tested the software. You don't contribute with anything meaningful to the discussion. You ask questions that there are already in the thread. What's the point of even commenting? Waste your time and others people time? How can you even pretend that someone that describe its software to be on a "completely different level" and suggest you to leave the room and optimize the files at night can give you a falsifiable description? Are those question truly so naive or they are just rethorical and you are just acting as naive? (Which I don't know what can be worse)

"I'm curious what it is that I'm hearing after a file optimization is performed." This spoon feeding is pretty boring.

This question was already made and it's in this thread, reposted at page 15.

The adjective "well" can be contested, you're right, the test is not perfect but the reason is that there's a missing pre-requisite: first of all what you test must have been proven to exists. As I already offered you, I'm eager to spend my own time and repeat the test applying your suggestions. Or you can actually test it yourself to contribute to the discussion and to corroborate the results. The objective behaviour of this software is meaningless for audio quality, I'd like to get a peek at the code and decompile it but I've yet to decide if it's really worth the effort...

- I'm not an expert in blind testing protocols - In the meantime its clear that 'well executed' was just an empty boast. I mean, pick one.

"positive testing and listener training are necessary when the phenomenom Is proven to objectively exists" I mean, if you can provide me some positive controls and some kind of training that I should require with this kind of test I will be more than happy to repeat It. (If you're interested in)