Chargement...
 
[Voir/Cacher menus de gauche]
[Voir/Cacher menus de droite]

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

> Forums de discussion > 1 - Le matériel et les pilotes ALSA, FFADO, ... > [résolu] limits.conf : 100 pistes à 96 kHz 32 bits, latence 1 ms sans Xrun !
Dernier post
Page : 2/2   -   Aller directement à la page : 1  2 

[résolu] limits.conf : 100 pistes à 96 kHz 32 bits, latence 1 ms sans Xrun !

l_d_v_c utilisateur non connecté
''édit : À NE PAS FAIRE.

Le forum ayant planté je ne vais pas tout réecrire.

http://forum.ubuntu-fr.org/viewtopic.php?id=1092821

Résumé :
/etc/security/limits.conf
édit : modifier /etc/security/limits.d/audio.conf

@audio - rtprio -10
@audio - nice -1 #Édit : valeur indéterminée, peut-être -15 pour nice ? lire la suite...

Enregistrement simultané de 10 pistes à 96 kHz en 32 bits flottants pendant la lecture de 90 pistes pendant 5 mn avec Audacity sous Tango Studio avec une latence de 1 ms SANS XRUN !

Jack : 32 échantillons par période
Fe : 96000 Hz
3 périodes par tampon.

Si ça fonctionne bien chez tout le monde, en tout cas le bureau devient très réactif, alors je propose de modifier la documentation.

J'attends vos retours.
Cordialement,
Ludovic

l_d_v_c utilisateur non connecté
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.

angelnwi utilisateur non connecté France
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.

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

angelnwi utilisateur non connecté France
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.

l_d_v_c utilisateur non connecté
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.

pierrotlo utilisateur non connecté Suisse
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 ?

l_d_v_c utilisateur non connecté
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 :

ludovic@ludovic-desktop:~$ cat /etc/security/limits.d/audio.conf
# generated by jackd's postinst.
#
# Do not edit this file by hand, use
#
#    dpkg-reconfigure -p high jackd
#
# instead.
@audio   -  rtprio     -10
@audio   -  memlock    unlimited
#@audio   -  nice      -1

ludovic@ludovic-desktop:~$ cat /home/ludovic/.jackdrc 
/usr/bin/jackd -T -dfirewire -r96000 -p32 -n3
ludovic@ludovic-desktop:~$ uname -r
2.6.31-11-rt


pianolivier utilisateur non connecté France
@ludo
Utilises-tu rtirq ?
Et que donne la commande ulimit -r chez toi ?

pierrotlo utilisateur non connecté Suisse
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 à :

@audio   -  memlock    unlimited


Ensuite dans ton audio conf, je remarque que :

#@audio   -  nice      -1
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à

l_d_v_c utilisateur non connecté
ludovic@ludovic-desktop:~$ rtirq
rtirq : commande introuvable
ludovic@ludovic-desktop:~$ ulimit -r
18446744073709551606


pianolivier utilisateur non connecté France
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

pierrotlo utilisateur non connecté Suisse
@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 biggrin 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

pianolivier utilisateur non connecté France
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'

l_d_v_c utilisateur non connecté
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

Page : 2/2
1  2 
Afficher les articles :
Aller au forum :

Documentation [Afficher / Cacher]

Faire un don
[Afficher / Cacher]

Connexion
[Afficher / Cacher]



Mégaphone [Afficher / Cacher]

olinuxx, 12:30, ven. 24 Sep 2021: Bonjour à et bienvenue à kitty32, beldic2, et à Carlos54 cool
olinuxx, 21:29, mer. 22 Sep 2021: Bonjour et bienvenue à tezere cool
funroad34, 15:50, lun. 20 Sep 2021: c est surtout lors de la connection que ça rame sinon c 'est correct niveau timming a l'ouverture des pages..
funroad34, 15:43, lun. 20 Sep 2021: slt Oui patience et perseverence...
Houston4444, 11:17, lun. 20 Sep 2021: Ici on apprend la patience, bientôt la cafetière aura terminé sa mission avant que la page soit chargée...
sub26nico, 17:50, dim. 19 Sep 2021: pas de souci ici
funroad34, 14:14, dim. 19 Sep 2021: Bonjour idem chez moi
Geis007, 18:03, sam. 18 Sep 2021: binjch, c'est très lent, en effet !
binjch, 22:51, ven. 17 Sep 2021: Salut c'est hyper lent chez tout le monde là? Ou c'est moi qui ai un problème?
olinuxx, 18:46, jeu. 16 Sep 2021: Bonjour et bienvenue à pierre2 cool
zicstef, 22:40, mer. 15 Sep 2021: Hello, il y a bien longtemps que je n'ai pas eu la joie de passer. Découvert au détour d'un surf: /
olinuxx, 18:30, lun. 13 Sep 2021: [INFO] nouveau compte Diaspora pour linuxmao : [Lien] Venez nous y rejoindre cool