ROON in Virtual Machine of NUC – Geen verschil

Er zijn heel wat gesprekjes en ‘draadjes’ te vinden over voedingen op ‘ROON’ NUC’s of andersoortige tweaks voor ROON-servers. Nu draaien we al tijden ROON Rock op een Gigabyte Brix NUC (Core i5-model). En we zijn bijzonder tevreden. Respons is snel – ook met veel zones – en weergave is heerlijk. Aangezien we ook benieuwd zijn of tweaks daar wat doen, hebben we ROON in een VM (Virtual Machine) geïnstalleerd en dat vergeleken met onze Brix die we voor deze test voorzien hebben van een Sbooster lineaire voeding. Is er een verschil hoorbaar? 

Nee… punt. Er is geen verschil hoorbaar.

En nu de uitleg

De set-up van deze twee machines is vrijwel gelijk: ROON Rock is in feite een uitgeklede linux-versie van ROON. We hebben daarom Ubuntu op onze Unraid-server (RAID-array, SSD-cache, 10-core Xeon (E-2690V2) met 48GB RAM) in een Virtual Machine geïnstalleerd. We hebben 2 cores / 4 threads en 8GB RAM toegewezen aan deze Ubuntu-installatie. Dat is ongeveer vergelijkbaar met de Core i5 van de NUC. In deze Ubuntu-install hebben we vervolgens de Linux-versie van ROON geïnstalleerd.

Nu is het mogelijk om continu te schakelen tussen deze twee installaties, maar we wilden het gemakkelijker doen: we hebben twee Metrum Acoustic Ambres die we via coax aansluiten op de Pavane-dac. Zo kunnen we snel schakelen tussen deze twee servers. Gewoon dezelfde track starten en input wisselen. Gemakkelijker wordt het niet.

Processing

In feite doet de ROON-server niet veel meer dan een datastroom van (muziekdata) verwerken en naar een endpoint sturen. Dit gaat via het zogenaamde TCP-protocol – Transmission Control Protocol. Dit is een protocol (onderdeel van de ip-stack) dat correctie kent. Het is een zogenaamd verbindingsgeörienteerd protocol. Dit in tegenstelling tot UDP (zonder correctielayers). UDP kent in basis geen foutcorrectie. TCP wel. Oftewel: er kunnen bij TCP geen fouten in de data ontstaan.

Dit hoeft natuurlijk niet te betekenen dat er geen verschillen waarneembaar zijn. Immers: bij netwerkkabel horen wij ook verschillen. Dat komt door de elektrische verbinding die u legt tussen uw netwerk en de streamer. Maar… dit probleem speelt ook niet echt bij een ROON-server. Het draait immers op een pc, NUC, NAS… Dat ís het vervuilende element.

Wat over zou kunnen blijven is jitter. Maar dit kunnen we ook vrijwel direct buitensluiten. Want streaming – ook bij ROON – is packet based. In de header van het datapakketje staat van wie het komt, waar het naar toe moet, waar het thuis hoort in de datastroom (de ID / datagram, ondersteund met de flag en de fragment offset). Jitter zoals we die kennen bij bijvoorbeeld spdif speelt hier geen rol, omdat de ontvangende kant gewoonweg de datapakketten ontvangt en deze in de buffer aan elkaar lijmt er er een muziekstroom van maakt bij de decoding. Zolang dit goed gebeurt, kan er geen verschil zitten tussen bron A en bron B.

Processorkracht?

Is processorkracht dan een bepalende factor? Dat zou kunnen. Een ondermaats platform zou fouten kunnen maken. Maar dan zal dit zich gaan uiten in tikjes, uitval, zeer trage respons. Niet zozeer in klankkleur of imaging. Redacteur in kwestie draait privé ROON op een Synology NAS (DS1517+ met 8GB RAM en SSD-Cache) en dat draait uitstekend met twee soms drie zones actief. En we kunnen een quad core Intel Atom nou niet echt een powerhouse noemen. Toch?

Concluderend

Of u nu ROON op een NAS draait, een NUC, een peperdure desktop, in een Virtual Machine… het maakt klankmatig niet uit. Wij hebben echt geen verschillen waargenomen. Dus vergeet die dure tweaks aan de serverkant van ROON… Tenzij u een NUC in hetzelfde stekkerblok van uw hifisysteem doet (soms ontkomt u er niet aan), maakt het echt niets uit of u nu de laptop-adapter of een lineaire voeding eraan koppelt. Zorg voor een fatsoenlijke netwerk-ontkoppeling en u bent echt helemaal het mannetje of vrouwtje.

Video server-rek Alpha Audio