Optimisation du Buffer

[r11bordo]

Attention à ne pas mélanger les choux et les carottes... Les éléments partagés juste au dessus sont les buffer systèmes Alsa.
Les buffers stream/output sont purement applicatifs propres à Squeezelite et permettent de limiter l'impact induit pas le réseau, visiblement.

[zaurux]

Oui, nous sommes d'accord, c'est ce que j'indiquais.
C'est pour cela qu'il faudrait peut-être renommer le post car cela concerne uniquement Squeezelite.
J'ai fait le parallèle avec Roon puisqu'un peu plus haut, on a parlé des réglages "streamer" dans les configurations de Roon et qui impactent Alsa côté "player" en fonction des choix ('defaut', 100ms, 500ms).
Les buffers de Roon Core ont été optimisés pour sécuriser le stream particulièrement avec la version 1.5 (Qobuz & Tidal).

[rastabill]

(02-23-2020, 11:31 AM)r11bordo a écrit : Bon, j'ai fait pleins de tests hier, la vraie différence se situe avec valeur ou sans valeur de buffer...
La définition d'un buffer quelqu'il soit amène plus de liant, plus de précision dans la scène sonore. Cela sonne moins 'harsh' donc plus fluide et on gagne en profondeur.

Pour le ressenti c'est tout a fait cela qui avais été mis en évidence par les utilisateurs de Tinysqueeze et actuellement ceux de Daphile fonctionnant tous deux sur Nuc ou carte mère à base Intel.

[rastabill]

(02-23-2020, 03:39 PM)Vincent. a écrit : En revanche je me pose la question pour mon serveur à base de RPi3 et DD sur le port USB, de passer à la RPi4 qui a 2 puces distinctes.

A mon avis tu doit y gagner le processeur gérera mieux les interruptions ily a forcément des requêtes qui arrivent aux même moment pour le réseaux et l'usb. Qu'il soit séparés sera mieux pour le Proc.

[rastabill]

Je précise que je suis pas utilisateur de Picore player, Volumio ou MoodO mais que je participe à ce fil pour essayer d'aider.
Je suis nul en linux.... donc il faut voir les spécialistes
Le résultat ne sera pas immédiat, il faut faire beaucoup de test car il y a plusieurs combinaisons .
Certain paramètres ne seront peut être accessible uniquement en ligne de commande. 
Le Rpi3 n'étant pas idéal pour la gestion du réseau et de l'usb. 
Les reglages ci-dessous concerne les utilisateurs de Nas(lms dessus) ou DD sur box avec un Dac  connecté en Usb.

------
L'idée des buffers inversés, pour expliquer, c'est de remplir les données en mémoire en priorité pour libérer les accès à l'usb. 
le buffer d'entrée plus important limite le nombre d'accès ce qui rend disponible l'accès à l'usb. 
je pense que ce l'on a constaté sur Tinysqueeze et Daphile sur Nuc ou Brixj1900 devrais s'appliquer au Rpi3. 
------
Il y a un paramètre qui joue également c'est le Nrpacks. 
sur limage des réglages PicorePlayeur
il serait intéressant de savoir a quoi correspond le 1 après le 80  4



si c'est bien le Nrpacks il faut esssayer 8 ou 16 voir 20
ce chiffre donne la taille du paquet qui part dans l'usb, ce qui a immédiatement un impact sur le nombre d'accès. 
Tous les réglages bien réalisés ont un impact sur la latence de votre Rpi3. 

--------
des infos récupéré sur le Net
je n'ai pas retrouvé mes notes de l'époque (crash PC). 
-------

Nrpack et Usb
Une autre grande différence entre le NSLU2 et le Pi est que le port Ethernet du Pi est implémenté en interne sur le bus USB. (Le système sur puce du NSLU2 possède une interface Ethernet dédiée qui est distincte de l'USB, mais je comprends que ce n'est pas le cas avec le Pi.) Je trouve que le problème de distorsion est beaucoup plus important si la lecture audio est diffusée en continu quelque part le réseau (en particulier à bande passante élevée); ce n'est pas si mal lors de la lecture d'un fichier audio qui a été stocké sur la carte SD du Pi. Par conséquent, je pense qu'une sorte de conflit de bus entre Ethernet et audio USB pourrait se produire.
Il est possible d'augmenter la quantité d'audio envoyée au périphérique USB à chaque "rafale", rendant ainsi le timing USB moins critique. Cela peut être fait en augmentant le paramètre "nrpacks" du module snd-usb-audio du noyau de sa valeur par défaut de 8 à son maximum de 20. C'est-à-dire éditez / etc / modules et assurez-vous qu'il inclut:
snd-usb-audio nrpacks = 20
avant toute autre ligne de fin (le changement prend effet au redémarrage). Pour modifier les nrpacks dans un système en cours d'exécution, faites:
rmmod snd-usb-audio
modprobe snd-usb-audio nrpacks = 20
et pour vérifier que le changement a eu lieu, faites:
cat / sys / module / snd_usb_audio / parameters / nrpacks
qui devrait maintenant dire 20. J'ai trouvé que cela semble réduire la distorsion, mais ne la supprime pas. Je voudrais essayer des valeurs supérieures à 20, mais cela nécessitera la compilation d'un noyau Linux personnalisé (la limite de 20 est donnée par la définition de MAX_PACKS dans la source du noyau à sound / usb / card.h; je voudrais essayez de l'augmenter à 100 lorsque j'aurai le temps de comprendre comment compiler un noyau Raspbian).
Bien sûr, la carte USB elle-même aura une limite matérielle du nombre de paquets "à lire" qu'elle peut accepter, ce qui pourrait être inférieur au nombre de nrpacks. Je ne sais pas s'il existe un moyen de savoir combien de paquets la carte accepte réellement.
---------
AvecTinysqueeze on a accès directement a beaucoup de réglages  pour Alsa (prog qui gère laudio sous Linux) :
Alsa priority standart
Nrpacks 16
Squeezelight +plugin dsd
Ourput priority 51  (paramètre Alsa)
Alsa buffers 93 ms ( paramètre Alsa) ou186
Alsa periods 4  (paramètre Alsa) ou 8
--------
Pour un Rpi3 à la mémoire limitée 
On peut utiliser pour les buffers inversés pour débuter 
16384Kb
4096Kb
Pour Alsa
le 32 /2 est plus difficile a gérer pour le Rpi3 (Aredien la bien noté) 
80 /4  ou 186 /8 sont parfait

---

Pour les Utilisateurs de Roon je pense qu'il ny a pas grand chose à grater c'est déjà mis dans le Prog... c'est payant

[l'Arédien]

(02-24-2020, 11:46 AM)rastabill a écrit : Il y a un paramètre qui joue également c'est le Nrpacks. 
sur limage des réglage PicorePlayeur
il serait intéressant de savoir a quoi correspond le 1 apres le 80  4



si c'est bien le Nrpacks il faut esssayer 8 ou 16 voir 20
ce chiffre donne la taille du paquet qui part dans l'usb, ce qui a immédiatement un impact sur le nombre d'accès. 
Tous kes reglages bien réglé a un impact sur la latence de votre Rpi3. 

Voici les explications que donne PcP sur ce paramètre : 

[r11bordo]

(02-24-2020, 11:46 AM)rastabill a écrit : L'idée des buffers inversés, pour expliquer, c'est de remplir les données en mémoire en priorité pour libérer les accès à l'usb. 
le buffer d'entrée plus important limite le nombre d'accès ce qui rend disponible l'accès à l'usb. 

Je me permets un petit ajustement. Le nbpack n'a rien à voir avec l'USB, c'est le nombre de découpage de la trame buffer Alsa. Ensuite les paquets sont envoyés vers le périphérique audio, vers l'USB s'il s'agit d'un dispositif USB (déconseillé sur un RPI3 et inférieur du fait du partage du chipset RJ45 et USB), ou vers la carte HAT s'il s'agit d'une carte connectée en GPIO (là, c'est tout à fait compatible avec l'audio).


J'aurais tendance à choisir une taille de buffer suffisament grande pour éviter les accès et les interruptions systèmes à répétition pouvant générer à un certain seuil des clicks ou des perturbations. Je n'ai jamais compris d'ailleurs ces audiophiles cherchant à atteindre le seuil minimum à partir duquel les clicks disparaissent. Perso, je m'oriente vers la direction inverse.

Pour ce qui est des paramètres ALSA disponible à travers l'interface pcp, c'est un abus de language amha. C'est du paramétrage système permis par pcp mais c'est finalement externe à PCP même si Squeezelite l'utilise.

[moonfly]

J'aurais tendance à choisir une taille de buffer suffisament grande pour éviter les accès et les interruptions systèmes à répétition pouvant générer à un certain seuil des clicks ou des perturbations. Je n'ai jamais compris d'ailleurs ces audiophiles cherchant à atteindre le seuil minimum à partir duquel les clicks disparaissent. Perso, je m'oriente vers la direction inverse.


Bonjour,
peut être pour éviter le décalage du son sur une image (TV)
ou sur un instrument de musique quand une table de mixage est branchée sur un PC par exemple, si un musicien joue une note et qu'il l'entend un quart d'heure après (s'exagère) c'est pas terrible.
C'est pour ça que le temps rée,l relié directement au noyau (linux) avec utilisation de la totalité de la mémoire et zéro latence est recherché.

---

J'aurais tendance à choisir une taille de buffer suffisament grande pour éviter les accès et les interruptions systèmes à répétition pouvant générer à un certain seuil des clicks ou des perturbations. Je n'ai jamais compris d'ailleurs ces audiophiles cherchant à atteindre le seuil minimum à partir duquel les clicks disparaissent. Perso, je m'oriente vers la direction inverse.


Bonjour,
peut être pour éviter le décalage du son sur une image (TV)
ou sur un instrument de musique quand une table de mixage est branchée sur un PC par exemple, si un musicien joue une note et qu'il l'entend un quart d'heure après (s'exagère) c'est pas terrible.
C'est pour ça que le temps rée,l relié directement au noyau (linux) avec utilisation de la totalité de la mémoire et zéro latence est recherché.

---

(02-24-2020, 03:16 PM)moonfly a écrit : J'aurais tendance à choisir une taille de buffer suffisament grande pour éviter les accès et les interruptions systèmes à répétition pouvant générer à un certain seuil des clicks ou des perturbations. Je n'ai jamais compris d'ailleurs ces audiophiles cherchant à atteindre le seuil minimum à partir duquel les clicks disparaissent. Perso, je m'oriente vers la direction inverse.


Bonjour,
peut être pour éviter le décalage du son sur une image (TV)
ou sur un instrument de musique quand une table de mixage est branchée sur un PC par exemple, si un musicien joue une note et qu'il l'entend un quart d'heure après (s'exagère) c'est pas terrible.
C'est pour ça que le temps rée,l relié directement au noyau (linux) avec utilisation de la totalité de la mémoire et zéro latence est recherché.

---

J'aurais tendance à choisir une taille de buffer suffisament grande pour éviter les accès et les interruptions systèmes à répétition pouvant générer à un certain seuil des clicks ou des perturbations. Je n'ai jamais compris d'ailleurs ces audiophiles cherchant à atteindre le seuil minimum à partir duquel les clicks disparaissent. Perso, je m'oriente vers la direction inverse.


Bonjour,
peut être pour éviter le décalage du son sur une image (TV)
ou sur un instrument de musique quand une table de mixage est branchée sur un PC par exemple, si un musicien joue une note et qu'il l'entend un quart d'heure après (s'exagère) c'est pas terrible.
C'est pour ça que le temps rée,l relié directement au noyau (linux) avec utilisation de la totalité de la mémoire et zéro latence est recherché.

correction: il faut lire temps réel,

[r11bordo]

Hello,
Quelques problèmes de copier/coller dans le message ci-dessus on dirait.

Bon après plusieurs tests sur les taillles de buffers applicatifs, c'est bien ce que je pensais, le buffer <Stream>/<output> impacte le traffic réseau. Cela se voit surtout sur les formats CD où le traffic réseau peut être réduit par 10 avec buffer vs sans buffer. Selon la taille du buffer, la réduction du traffic est progressive et s'accélère avec la taille.
J'ai obtenu le meilleur compromis conso CPU/traffic réseau avec la valeur <125000>/<125000> ce qui consomme 250Mo de RAM sur le Go dispo avec le RPI3, et provoque un pic de consommation CPU et réseau de l'ordre de 3 secondes sans impact notable sur la restitution. 

Enjoy 

[kimbo]

Pour toi, le buffer inversé n'a pas d'effet ?