I ran Roon on a 2015 iMac and it worked fine. It is a relatively noisy environment though, and as Roon sends the audio signal through the computer, I found it didnât sound as good as using the Naim app and streaming direct from my Uniti Core.
I canât imagine the new M2 miniâs would have any problem with that and a lot more.
Iâll be using mine for Roon, MinimServer and HQPlayer as the licence I have is for the Mac version. Provided it improves the performance of Roon that is. The custom one is on itâs way to me now so itâll not be long before I find out!
I did. (Though it is to render the music as well.) and good it is, too. I did a brief comparison of it running Audirvana (fully optimised for sound quality) with the bottom of the range Melco, which cost quite a bit more, finding no discernible difference in sound quality. Had I not found Audirvana to be so good, I was going to drop back to use the MM as a NAS, in respect of which it did very well compared to the cheap basic NAS I had bought to start my streaming journey. It just sits there, on 24 hours a day, and responds on demand. IIRC it uses something like 5-7W on standby, is silent and unflappable - and although dedicated to music while playing for maximum sound quality, if I want I can use it for other things.
Well you make a good point, in this insane hobby I suppose a mini looks like good value!
After reading your comments I thought Iâd give this a try. Apart from some initial messing about with Qobuz when I first got the Linn, itâs been exclusively used with Roon.
Getting Asset setup on my Mac laptop was very easy - Iâve copied a few favourite albums across from my Nucleus to my laptop to test with. I had problems getting UPnP working on the Linn and Qobuz wasnât working either. Restoring the Linn back to factory settings and reconfiguring it again got both services working so itâll be interesting to compare Qobuz and local files (via Asset) compared to Roon.
The problem with judgements about Roonâs SQ are entirely based on network implementation, the gear being used and are a bit of a moving target tbh. I have tried various implementations and once optimised the differences between Roon and others are minimal IMO, however the benefits in flexibility and user case can outweigh sonic disadvantages. YMMV is the usual get out clause!
On a separate theme, the longevity of Roon is debatable of course, but my take is that Harman will release future products with Roon readiness baked in, sure of a software that generally works well and doesnât suffer the same âcross-pollinationâ issues when mixing brands in a home setup. This should make products more sellable if the networking functionality of Roon continues to be reliable. Weâve all experienced what poor networking software can do to enjoyment of your home system and those of us who have used Roon for any time know it generally works well. For those who donât like the idea, I suggest just buying a turntable, amp and speakers!
Iâm sorry you didnât have an optimal experience running Roon on a Mac. Many, many, others have had no issue with it. I just donât think itâs fair to muddy the waters with prospective Roon trialers thinking they need a proper âserver.â Itâs just an app, albeit a large one.
My MacBook Pro 16" M1 that I use for my business is on 24/7 with no issues. My NUC with Roon ROCK has been on 24/7 for years now (note that a NUC, recommended by Roon, is not a server). We leave our Naim devices on 24/7. I donât see why a Mac would be any different.
Oh I think my network was configured just fine, it just doesnât sound as good as other options
Just speaking from my own experience, there are definitely some subtle differences between the Roon implementation for the Linn streamers and the Linn app/Kazoo with regard to SQ, although both use the same UDP-based Songcast protocol, which is Linn proprietary technology.
I find Roon very good but it benefits from dedicated hardware and nice quiet power supplies and a nice simple quiet network without a load of stuff chattering awayâŚ
Thatâs a tall order for my house.
I kind of think that is unlikely., itâs all fairly standard TCP, nothing special, but I do think Roon endpoints differ in implementation. They can even vary between Naim firmware updates, just like DLNA, albeit very subtle.
But I cant hear, and my listening panel (some of my family) could hear no difference behind the scenes when switching the Roon server between Ethernet and WiFi (802.11ac) and no one knew what I was doing and what connection method was being used so I ruled out subconscious bias
If you use a switch and IGMP snooping to connect your streamer or WLC you wonât see network chattering on the streamer segment to your streamer, (this is the WHOLE purpose of using a network switch as opposed to the older style network hub). You will se what is required by the streamer, the media TCP flow, and occasional Roon management and the occasional ARP frame, and some other broadcast frames for your network integrity which in the grand scheme of things are just a drop in the ocean compared to the regular media TCP transfer and confirmation used by RAAT.
I think most home networks are quite benign places⌠and even more so if you use a switch and IGMP snooping.
The other consideration you will typically see a busier segment when cloud streaming to the streamer, such as from Qobuz, Tidal or Spotify⌠as the slightly longer RTD means the TCP confirmation windowing tends to work harder than if you are streaming from your home network with Roon or DLNA.
If you are curious to see for yourself if you only have a superficial understanding of home network, create a SPAN port mirroring your streamer port on your switch and feed into WireShark.
Despite this has been said a million times here and in the Roon forum and elsewhere, some members in this forum are not still convinced themselves, and prepared to spend tons of $$$ on useless gadgets, including the ones who sell HIFI stuffs for a living
Well if people want to flitter their money away, I guess one shouldnât stop them.
Well unfortunately the network / streaming world isnât that simply to just have TCP/IP solve the sound quality topic (of course things are bit-perfect always). There is jitter/noise - and people interested might have a look at 3:54 in https://youtu.be/sDiHFYHKij4?si=z0vcsbM1edQsEPh1
It depends what you mean as jitter. I think some confuse network jitter with audio sample jitter⌠this is the issue of attempted extrapolation from too little a knowledge. They are completely different and not related and on standard streaming protocols have no bearing on each other.
TCP is the transport protocol used for most home audio , and the data is packaged, batched, sent, confirmed, resent or request for the next package. There is no realtime serialisation of sample data, so by definition there no concept of sample jitter here. Even UDP is not directly connected to audio sample data and only becomes a consideration when using ultra low latency, such as high quality two way speech.
Another consideration is the phase noise (jitter) from the physical serial clock in the twisted pair or fibre⌠but this is more about noise coupling into connected devices between physical electrical or optical connections and not about network data.
BTW you might have confused TCP with TCP/IP? They are different. TCP is a connection oriented reliable transport protocol. TCP/IP is the collection of protocols and technologies that we use mostly today on the internet and private networks that is represented by a 4 layer network model. It has largely superseded the OSI 7 layer model in networks that was more prevalent in the 70s and 80s.
On sound quality and RoonâŚI have found that GTT Audio are absolutely and totally right ⌠not by blindly following what he saysâŚbut having discovered this my self by trial and errorâŚtake a lookâŚeven down to replacing the power cable between the powersupply and NUC. I have found Roon excellent but very dependant on itâs support infrastructure.
You did watch the video I linked?