AMBRE by Metrum Acoustics

[r11bordo]

Merci Baldoun pour les retours. 

Les tests que j'avais menés sur plusieurs distribs m'amèneraient à penser que certaines configs seraient de la bonne pratique :
- Préférence pour un noyau RT sur le drive (tel que l'ambre). Dans mes souvenirs, le noyau Real Time amène plus de fluidité pour une restitution un peu analogique, moins 'harsh'
- Déporter le serveur sur le réseau (tels que LMS). Un serveur local sur le drive empêche en général l'utilisation d'un noyau RT et permettra de disposer davantage de puissance qu'un RPI sur un drive et libère ainsi de la conso ressource matérielle en la déportant sur un server
- Le chargement de l'OS en RAM. Pas pu vraiment testé sur une même distrib mais j'ai toujours préféré le rendu des distribs travaillant en RAM plutot que celle fonctionnant depuis la carte mémoire. Accessoirement, le fonctionnement en RAM limite les accès lecture écriture de la carte mémoire et l'économisera
- CPU isolation à préférer sur les configs matérielles puissantes, sur RPI, mon opinion est que c'est incompatible avec un usage audio ...
- Alsa seting : je préfère les gros buffers et accès mémoire activés plutôt qu'un paramètre fixé à la limite de l'instabilité audio avec des clics, des plocs dans les enceintes, etc ... mais chacun voit midi à sa porte :-)
- Les buffers : paramètres très importants pour limiter l'influence des câbles et switchs réseaux. Gains vraiment appréciables sur l'Ambre avec PCP qui charge finalement les pistes en RAM plutôt que par petites trames réseaux récupérant toute la pollution associée. Sur pcp, ce paramètre est dynamique et l'apport de ce paramètre est perceptive en live.

---

(04-01-2020, 08:41 PM)roddek6 a écrit :

(04-01-2020, 08:36 PM)chakiwi a écrit : @ roddek un cpu à 60° c'est rien d'anormal, si inquiet il faudra envisager un radiateur plus performant

Merci pour le renseignement, mais voila ce que j'ai

[color=rgba(0, 0, 0, 0.87)]─────────────────────────────────────────────────────[/color]
[color=rgba(0, 0, 0, 0.87)]Gentooplayer CPU Info[/color]
[color=rgba(0, 0, 0, 0.87)]Use cpu-governor to change CPU / performance options[/color]
[color=rgba(0, 0, 0, 0.87)]─────────────────────────────────────────────────────[/color]
[color=rgba(0, 0, 0, 0.87)]Architecture |     aarch64[/color]
[color=rgba(0, 0, 0, 0.87)]Temp         |     60'c : 140'f | Running hot, not recommended.[/color]
[color=rgba(0, 0, 0, 0.87)]Governor     |     performance[/color]

[color=rgba(0, 0, 0, 0.87)]               Current Freq    Min Freq   Max Freq[/color]
[color=rgba(0, 0, 0, 0.87)]CPU0         |      1400 MHz      600 MHz    1400 MHz[/color]
[color=rgba(0, 0, 0, 0.87)]CPU1         |      1400 MHz      600 MHz    1400 MHz[/color]
[color=rgba(0, 0, 0, 0.87)]CPU2         |      1400 MHz      600 MHz    1400 MHz[/color]
[color=rgba(0, 0, 0, 0.87)]CPU3         |      1400 MHz      600 MHz    1400 MHz[/color]

[color=rgba(0, 0, 0, 0.87)][ INFO ] GentooPlayer-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.[/color]
[color=rgba(0, 0, 0, 0.87)]- if the temperature is not displayed, first run the command: sensors-detect --auto[/color]

Il doit y avoir une option quelque part dans gentooplayer de type CPU Option = 'On Demand' ou Min Perf ou Max Perf. Choisir le On Demand qui positionnera la fréquence CPU en fonction de l'activité système. 
Ensuite 60°, sur un CPU sans radiateur, ce n'est pas étonnant, mais on reste loin de la température fatale pour un CPU (qui doit tourner autour de 100°). Par contre, je ne sais pas si les rpi sont dotés d'une protection contre les surchauffes avec arrêt du système, à vérifier.
Je précise également que c'est la température que j'avais observé quand j'avais installé Dietpi sur le rpi de l'Ambre.