1 - Le matériel et les pilotes ALSA, FFADO, ...

Jack en priorité par défaut. (pourquoi changer ?)

Mais comme je commence à faire fonctionner mon ordinateur maintenant, et que je ne dois pas inciter les autres à essayer les résultats de mes essais qui fonctionnent enfin dans la pratique, je pense que le mieux est la suppression pure et simple de mon compte sur Linux MAO.

Chez moi ça fonctionne en latence 0,5 ms à 96 kHz.
Par sécurité je repasse en latence 1 ms, ça me suffit, pas un seul Xrun bien évidemment.

Pour les autres, suivez les documentations, ou à coup de désespoir modifiez ces deux valeurs qui n'ont rien à voir avec le fait que l'ordinateur fonctionne enfin normalement (sans Xrun).

Matériel audio principale : carte son ECHO Audiofire 12 avec Super-Ordinateur S2915-E.

PS : je viens de passer le traducteur sur linux.die.net qui me dit : linux. mourir. net

Je rappelle que les informations que je donne sont issues de la pratique, et qu'il semblerait que ça fonctionne mieux chez pierrotlo qui a suivi rtprio -10.

Reste à définir ensemble nice. Je vais suivre pierrotlo et mettre -15. Mais ça me gène d'avoir nice plus prioritaire que rtprio. Dans ce cas, rtprio doit être compris entre -20 (priorité maximale qui peut interférer avec le système) et -15 (priorité plus importante que nice).

J'édite mon premier message en suivant tes conseils pianolivier.

à+
Ludovic
PS : désolé si je suis émotif mais l'ordinateur fonctionne enfin après toutes ces années passées à suivre la documentation.

J'ai testé aussi de modifier le rtprio, à 10 j'accumule les Xrun dès que je lance une application quelconque, due certainement aux accès disques. Deuxième problème que j'ai eu c'est une augmentation significative de la charge cpu. Du coup, je suis revenu à un rtprio de 90. Pour info, sur ma config, ce qui m'a permis de réduire drastiquement les xrun et la latence ça a été d'enlever pulseaudio et de recompiler mon noyau en basse latence avec les bons réglages pour les modules. Mon jack est réglé à 48Khz, avec une période de 64 et un tampon de 2. Qjackctl m'indique une latence de 2,67 dans la page de config et de 0ms dans les status. Ardour me donne 1,3 ms. Tout ça après plus de 6h de fonctionnement et 0 xrun.

Je n'ai jamais parlé de rtprio à 10 !...
Comme quoi un '-' (signe moins) a toute son importance.

Autant pour moi, à -10 aucune différence avec 90, en sachant que jack a une priorité de 80 donnée au ps. J'ajoute aussi que nice est commenté dans mon audio.conf. J'ai lu (je me souviens plus où) qu'avec le noyau 3.2 cette ligne n'était n'était plus utile.

Pourtant 90 ne semble vraiment pas fonctionner sur le noyau 2.6.31-11-rt.
Ok pour -10.
Hier j'ai fait un truc formidable à l'échelle de mon ordinateur :
rtprio à -1
nice à -15 ou -1.. dilemme
Plein de programmes ouverts dont : thunderbird et firefox, Skype ! (lui qui faisait tout planter fonctionne enfin avec audacity), et audacity en relecture de 70 pistes à 96 kHz / 32 bits pendant l'enregistrement de 10 nouvelles pistes en plus.

Salut,

Ok j'ai fini les tests sur deux machine. Les conclusion pour ma part sont les suivante :
1) dans /etc/security/limits.d/audio.conf, le nice -1 fait planter le système qu'elle que soit la machine.

2) avec rtprio -10 ce matin aprés près de 12 heures de fonctionnement, aucun 2 xrun. (Qmidiarp fait tourner 3 synthés différend, mais pas zynaddsubfx). En fait le même résultat qu'avec un rtprio à 90.

4) avec un rtprio à -10 et QmidiArp -> zynaddsubfx en son de base, au bout de deux heure, jack se met à aligner les xruns (170000 environ) avant de planter. Idem avec un rtprio 90. Donc, le problème est du à zynaddsubfx ou plûtôt à certains de ses modules.

Disons que les tests ne sont pas vraiment concluant.

Maintenant, j'aimerais comprendre. Tu dis à un certain moment tourner à 1ms. Je ne vois pas vraiment comment ? 32 échantillon à 3 tampon me donne 2 ms, 16 échantillons à 3 tampons me donne effectivement 1ms.
Je doute fortement que jack démarre dans ces conditions avec du firewire.

L'idée serait la suivante. Pourrais tu envoyer le contenu de ton /etc/security/limits.d/audio.conf et un screenshot de ta config jack ? et le contenu de ton fichier .jackrc sous ton home ?

Salut pierrotlo, hier j'ai modifié nice -15 pour faire comme toi...
impossible de démarrer Jack !

1) De retour à nice -1, jack démarre en 32 - 96000 - 3 soit 1 ms de latence à 96 kHz...
(Jack plante avec nice -15)

1352278280.png
1352278515.png

Je cherche encore à améliorer ceci car même s'il n'y a aucun Xrun, l'ouverture de skype 4.0.8 génère parfois un Xrun. (Skype n'a aucun intérêt dans le studio, c'est juste pour éprouver le système).

Comme je soumets le doute plus haut : partant d'un point de repère de rtprio -10, cela me gêne de voir nice -15 car il aurait plus de priorité que le RT. (ce qui est une erreur à mon sens, et n'engage que mon passé sur AmigaOS multitâche préemptif, à base Unix), je vai srefaire des essais avec nice -5.

Je peux aussi te montrer Jack qui démarre en 16 - 96000 - 3 avec 0,5 ms de latence.

En attendant, les images sont plus haut dans ce message et voici :

@ludo
Utilises-tu rtirq ?
Et que donne la commande ulimit -r chez toi ?

Heueh je n'ai jamais écris nice -15
mais
rtprio -15...

A nice -1 cela me plantait le système. Voir message plus haut
sur le Taliesin ulimit -r me donne ...

18446744073709551606 ?!? Je ne sais pas à quoi cela correspond. d'autant plus que dans le man de ulimit l'option -r n'est pas présente.

ulimit tout cours me donne : unlimited ce qui est normal car cela correspond dans mon audio.conf à :



Ensuite dans ton audio conf, je remarque que :

est commentée (le # au début de la ligne). Donc la commande nice n'est pas active. Comme on te l'a dit plus haut, cette ligne est automatiquement commentée lors de l'installation de jack car elle n'est plus nécessaire (en tous cas sur la version ubuntu 12.04)

La différence viens de ce que j'utilise un kernel RT 3.2 alors que toi tu es en RT 2.6.

Angelnwi dans son message un peu plus haut l'a cité et cela semble correspondre.

Donc pour toi et ceux en kernel 2.6 cela peu effectivement avoir une influence
De même il me semble (de mémoire) que dans les nouveaux kernel, rtirq n'est plus utilisé.
D'ailleurs, sur le Taliesin en 12.04 il n'est pas installé.
Voilà

Cela veut dire que rtprio est fixé à 18446744073709551606, et non à -10 comme tu le penses.
Il faut bien comprendre que le noyau linux possède plusieurs "shedulers", mécanismes qui ordonnent la priorité des processus pour répartir les ressourses. Le sheduler standard se base sur la valeur nice, et l'échelle est négative. Les shedulers temps-réels se rajoutent par dessus, utilisent d'autres valeurs et une autre échelle, positive. Dans l'ordre de priorité on aura donc par exemple une application avec nice -5, une autre avec nice -10, une troisième avec rtprio 10 et une dernière avec rtprio 20. Les deux premières applications ne tournent pas dans la même couche que les deux dernières.
Il est possible de voir les priorités non-temps-réel (nice) avec la commande ps -l.
Il est aussi possible de voir les priorités temps-réel, pour cela j'utilise la commande suivante qui affiche les sous-processus (threads) qui sont gérés par le sheduler temps-réel FIFO (FF) :
ps -Leo pid,class,rtprio,cmd | grep FF

Comme je l'ai déjà dit, rtprio doit être compris entre 0 et 100. Je peux voir chez moi que sooperlooper a une priorité temps-réel de 65, et différents sous-processus de jack ont différentes priorités aux alentours de 70 (défini dans ses paramètres).
Que se passe-t-il lorsqu'on défini une valeur négative pour rtprio ? Je n'ai pas réussi à trouver de doc là dessus, mais seulement ceci dans une des pages de manuel citées plus haut :
negative numbers cannot be specified as resource limit values, since they typically have special meanings (le paragraphe ne concerne pas nice qui lui utilise des nombre négatifs contrairement aux autres, justement)
Donc rtprio = -10 aurai une signification spéciale ?
Aller j'essaye après tout ce raffus, rtprio -10 et c'est partit. Résultat : sooperlooper et jack ont toujours les mêmes priorités positives. Un petit tour du coté de ulimit -r qui m'annonce "unlimited", tout fonctionne donc comme avant. Pourquoi ce nombre à ralonge chez toi et unlimited chez moi ? Je ne sais pas trop, il doit s'agir d'une différence d'implémentation ou de compilation, j'utilise gentoo mais le résultat est le même au final.
Voilà j'espère avoir enterré le mythe du rtprio négatif.

Ensuite il y'a sûrement des raisons qui font que ça fonctionne mieux chez toi, peut-être l'utilisation de nice. Mais cela n'améliore que la fluidité des graphismes, pour forcément de l'audio.
Le problème principal, c'est qu'il y a aussi des raisons pour lesquelles ça ne fonctionnait pas à l'origine, j'en vois plusieurs :

• tu n'as pas lu les tutos
• tu n'as donc pas installé rtirq qui est obligatoire avec un noyau RT sous peine d'obtenir... des x-runs.

C'est dommage, nous disposons de la meilleur documentation du net sur le sujet, toutes langues confondues. Enfin, j'espère que tu as compris ce qu'il te reste à faire, tout est dans le dossier Temps-réel pour les applications.

oliv'

ps @ pierrotlo : t'as raison, bien pauvre le manuel, ulimit -a pour tout afficher et apprendre les options par la même occase

@Olivier,

tu as entièrement raison en ce qui concerne rtirq. La seule adaption est que selon le système, rtirq se trouve à des endroits différents et pque par exemple sur ma version Ubuntu le package s'appelle rtirq-init.
Il semble même qu'il soit installé par défaut en même temps que le kernel Realtime.

En jouant sur les paramètres, la machine QuadCore qui me posait quelque soucis avec ZynAddSubFx tourne maintenant depuis près de 12 heures sans Xruns.

Ce genre de test n'est pas conforme à l'utilisation normale de la Mao 😀 c'est juste histoire d'essayer de la pousser au maximum afin de vérifier les réglages.

Maintenant, j'ai cherché aussi une chose sur le site linuxmao : comment déplacer les irq afin de mettre par exemple l'usb sur lequel se connecte la Xenix se trouve en 9 par exemple.

Je ne peux pas bloquer l'acpi (acpi=off) au démarrage, ce qui me libèrerais l'irq 9 parce que la machine ne démarre pas et le BIOS n'offre aucune possibilités (je n'ai d'ailleurs jamais vu un BIOS aussi peu fourni). Au pire je démonte la machine afin de virer le wifi, la webcam et d'autre périphérique USB.

Qu'en penses tu ?

Bien à toi

Pierre

J'en pense que tu arrives à la limite des possibilités et des mes connaissances.
Du coté matériel les IRQ ont eux aussi une priorité (à duckducker pour trouver l'ordre), et s'il n'y a pas d'interrupteur dans le bios pour désactiver certains IRQ prioritaires alors il faut il aller au fer à souder (ou en changeant le slot de cartes pci quand c'est possible dans certains cas).
rtirq permet seulement de modifier la prio temps-réel des processus greffés aux IRQ, quand on met ses périphériques importants en haut de l'échelle (90-100), les autres gardent une priorité d'environ 50 ce qui reste quand même inférieur à la priorité des applications audio (généralement entre 50 et rtprio=90).
Ce qui est sûrtout important je pense est que plusieurs processus ne partagent pas d'irq, par exemple le module d'une carte son firewire et celui d'une carte wifi. Dans le cas ou on peut pas désactiver la carte wifi matériellement, on peut toujours blacklister le module (évidement elle ne fonctionnera plus).
De mon coté j'ai donné au module acpi une haute priorité (environ 95) car j'ai remarqué que sinon parfois il "sautait" et c'est embêtant dans mon cas (la machine est un serveur headless, si le seul bouton qui en constitue l'interface ne fonctionne pas...). Mais je ne le conseillerai sûrement pas à tout le monde.

oliv'

Bonsoir,
j'avoue ne pas avoir lu l'immensité de la documentation. Le pire est que mes problèmes se sont surtout résolus au passage à Tango Studio et je me croyais encore sous Ubuntu...
Le coup des priorité de -10 qui se comportent comme 90, bien j'essayais de m'y faire. Ou plutôt non. Je ne touche plus à rien, et je continue d'investir matériel pour me passer du logiciel.

En passant à Tango Studio (en suivant les conseils d'un copain au moment où j'étais en train d'abandonner mon rêve de studio logiciel sous Ubuntu ayant trop galéré pour rien) j'ai pû installer *facilement* le noyau RT car je ne suis pas informaticien et je ne veux plus l'être.

Tango Studio est presque plug and play, parfait pour ma pauvre tête.

Le pire est que je sature dans le sens que je ne comprends plus ce que je lis.

J'ai reçu ce midi la clavier UMX490 et puisque je n'arrive pas à faire fonctionner Ardour, bien je vais travailler au séquenceur matériel. Puis Audacity pour finaliser.

Je décroche.
Je présente mes excuses : j'ai juste confondu le coup de ces priorité négatives, avec des priorité importantes, mais tout venait de tango studio et du noyau RT...

Ludovic