Roon

[volpone75]

Je ne crois pas qu'il faille faire de fétichisme sur le nombre de process et la charge CPU / RAM du serveur. L'essentiel est que cela ne talonne pas et que les données soient transmises correctement au player, c'est ce dernier qui idéalement peut ou doit être optimisé pour l'audio. Le serveur est fait pour être chargé et qu'il le soit plus ou moins n'est aucunement un critère de qualité sonore, c'est de l'informatique.

Pour illustrer concrètement voici la charge dans une architecture serveur (NUC) / player (RaspBerry PI3) typique.

Lecture d'un FLAC 16/44 upsamplé en DSD128 avec convolution (traitements beaucoup plus couteux qu'une simple lecture de FLAC).

• Le serveur (RoonServer) est sur un NUC i5 sous WIN10 non optimisé
  
• Le player "client" (RoonBridge) est sur un RPI3 de base en mode économie d'énergie sous LINUX optimisé (DIETPI).
  

1) CHARGE DU PLAYER sur RPI3 en mode "powersave" relié au DAC en USB , CPU à 600 Mhz max:

RoonBridge qui effectue la lecture consomme peu de ressources (load average quasiment nul):

• 22 process, 1 actif
  
• Charge autour de 13% sur un des quatre coeurs  (CPU tourne à 600Mhz)
  
• Mémoire utilisée autour de 100 Mo
  

PLAYER

2) CHARGE DU SERVEUR sur NUCi5, CPU 1.8Ghz en mode burst

RoonServer est beaucoup plus gourmand. C'est lui qui mouline et fait tout le boulot, mais il est distant de plusieurs mètres du DAC et pas relié directement à celui-ci.


SERVEUR

On voit bien dans cet exemple la différence très importante de charge entre le player et le serveur ROON mais surtout la très faible charge du player en lecture.

La conséquence est que la machine "player"  (à proximité du DAC et reliée directement à celui-ci) est très peu sollicitée et donc peu "polluante". L'exemple est en USB mais en SPDIF, avec la DigiOne par exemple, on aurait le même résultat.