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

[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

pianolivier utilisateur non connecté France
edit j'me suis gouré d'erreur, j'ai modifié mon message

salut ldvc,

déjà, merci pour tes tests et ton interet à améliorer le wiki.

Je suppose qu'on parle de la page PAM c'est bien ça ?

Si oui, je tiens à rappeler pour commencer que ce tuto à pour but de donner une config par défaut qui fonctionne au plus près des 100% possible, et qui permet de démarrer jack pour la première fois sans problème en conjonction avec Tuto Jack premier lancement.
Ces deux tuto ne sont pas orienté "ajustement de la latence au plus bas possible", ceci pourrai faire l'objet d'un nouveau tuto je suppose.

Donc ma première question est : est-ce que les valeurs données par ces deux tuto fonctionnent chez toi ?

il y'a une ligne qui concerne nice dans le tuto. As-tu lu les conseils de paul davis sur le sujet ? Pourquoi penses-tu que c'est érroné ?

Dans le même paragraphe tu trouveras plus d'explications sur les autres paramètres, ainsi que sur la page Temps-réel pour les applications (c'est un peu le bordel j'avoue, je ne me suis pas encore occupé à merger ces deux trucs)

la valeur rtprio est définie par toutes les docs que j'ai lu comme étant la limite maximale de priorité RT que les applications peuvent obtenir, comprise entre 0 et 100. Je pense que tu confonds avec un autre type de priorité, ça me rappelle vaguement quelque chose ce "plus la priorité est basse et plus prioritaire sera la tâche" mais ça ne s'applique pas ici (peut-être nice ?)

oliv'

l_d_v_c utilisateur non connecté
Bonsoir Olivier,
Merci.

J'avoue je n'ai pas forcément lu cette page en question mais tout ce que je sais est que plus la latence est minime, plus grands sont les risques de Xruns avec les paramètres donnés dans la documentation (LinuxMAO et Forum-Ubuntu-fr qui reprend ce site).

En pratique les valeurs données pour /etc/security/limits.conf n'ont jamais fonctionnées correctement chez moi, avec des obligation de tourner avec 2048 ou plus d'échantillons par période, une latence de 64 ms et un Ubuntu très chatouilleux qui subit des Xruns à la moindre occasion.

Pour nice, je ne vois pas trop mais vu sur le tas j'avoue que les valeurs que je donne plus haut pour rtprio et nice sont presque magiques car c'est le même matériel et maintenant ça fonctionne.

Maintenant, aucune raison particulière de souhaiter 1 ms de latence (quoique...) mais qui peut le plus peut le moins.

J'ai testé 100 pistes en latence 1ms, ce sont des tests, mais je peux maintenant revenir à 2 ou 4 ms pour m'assurer une sécurité.

Tu feras l'essaie avec les valeurs que j'indique, rien ne t'empêchera de tenter les valeurs du passé, mais normalement tu vas trouver un bureau hyper réactif, et sans Xrun.

Fianalement, c'est ce que tout le monde demande je pense.
à+
Ludovic

pierrotlo utilisateur non connecté Suisse
Salut,

pour nice je peux te répondre.

un nice -19 est la priorité maximale. Par défaut, dans un kernel RT, la priorité des processus en général est à nice 0. Priorité minimal étant de nice 19
J'utilise fréquemment la commande renice afin de donner une priorité plus èlevée à un processus. Je teste actuellement ce genre de manip.

Si cela peux t'aider, je vais tester tes paramètres sur une machine qui me gonfle un peu et je te redis.
Pour ma part, je test avec des applis assez délicate comme ZynAddSubfx + Phasex et le tout piloté par QmidiArp. JE laisse tourner en boucle jusqu'au plantage de Jack. Et il plante au bout de ...j'ai pas encore trouvé ! pour une machine, et pour l'autre, 48 heures aprés c'était toujours bon. Pourtant la première est bien plus puissante que la seconde (Quadri coeur pour la première et dualcore pour la seconde) .

l_d_v_c utilisateur non connecté
Bonjour,

Merci pierrotlo, "un nice -19 est la priorité maximale". Ça confirme mon questionnement apparemment justifié. Pas besoin de donner autant de priorité à nice car -1 suffit amplement (semblerait-il). En revanche rtprio pourra prendre des valeurs entre -10 et -19.
-10 est déjà une forte priorité. -19 pourrait *peut-être* interférer avec la gestion du système ou du noyau. À utiliser avec connaissance de cause.

En tout cas c'est génial. Ce couple -10 pour rtprio et -1 pour nice est facile à retenir et fonctionne merveilleusement bien sur mon bi-Quad maintenant.
Et quand je vois rtprio à 100 je ne peux que frémir... ça explique tous les Xruns passés.

ZynAddSubFX aucun soucis avec mes réglages du post#1, latence à 1 ms.

Je ne possède pas Phasex sur Tango Studio 1.2

Merci
à+
Ludovic

pierrotlo utilisateur non connecté Suisse
Salut,

j'ai lancé le test ce matin à 10h15.
Claudia pour lancer le truc et faire les connections
Zynaddsubfx pour un sybthé
Phasex pour l'autre

QmidiArp pour faire tourner une séquence (en fait une des séquences de démo)

Connecté aussi à un clavier externe Axiom 61.

Petite particularité, ma carte son USB Behringer Xenyx X1222 ainsi que la conneczion MIDI (Midimate) ne se connectent plus au démarrage. Il faut sortir les prise USB et les remettres. Je vais regarder si c'est dû au changement effectué dans /etc/security/limits.d/audio.conf (ubuntu 12.04 serveur).
Je te tiens au courant

l_d_v_c utilisateur non connecté
Merci pierrotlo,

je précise que j'ai testé ces paramètres sur Firewire, et je ne sais pas si c'est une bonne idée de copier à l'identique le paramètre 32 échantillons par période pour de l'USB...

Mais je pense qu'il faut garder -10 pour rtprio et que si cette valeur devient positive, c'est la panique et les Xruns s'enchainent...

pierrotlo utilisateur non connecté Suisse
Re,

1er essai : 15 minutes plus tard, il m'aligne des Xruns à ne plus savoir qu'en faire. 128 - 2 - 48000Hz. Donc pire qu'avant.

En 32 - 2 - 48000Hz -> jack ne se lance pas
Idem en 64 -2 - 48000Hz
Plus encore gel de X + LXDE le temps que l'application (claudia) se ferme pendant quelques secondes.

Une chose que je vois, c'est que tu modifie /etc/security/limits.conf.

Sous Ubuntu normalement c'est /etc/security/limits.d/audio.conf.

Peut être vérifier cela chez toi.

pierrotlo utilisateur non connecté Suisse
Pas mal de souci avec ces réglage.

Afin de démarrer une session :
j'ai laissé rtprio à -10
j'ai commenté la ligne nice -1

et 128 - 2 -48000Hz (peut être du à la latence USB tout simplement)
Bon ce n'est pas grave l'oreille ne percevant un problème de latence qu'à 25 ms à peu près.
Lors du lancement de la machine, cette fois les périphérique usb se sont chargé normalement.
J'ai relancé le test à : 10h30 . :-)

NB : merde j'ai pas encore changé l'horloge avec cette heure d'été : le test à débuté à 9h30.

l_d_v_c utilisateur non connecté
Pour de l'USB je ne pense pas que 32 soit adapté, en tout cas le 2 je ne pense pas, essaie -3 Périodes par tampon.-

l_d_v_c utilisateur non connecté
Quel noyau utilises-tu ?

ludovic@ludovic-desktop:~$ uname -r
2.6.31-11-rt


pierrotlo utilisateur non connecté Suisse
J'avais déjà essayé. Ce fut Niet.
Je pourrais aussi mettre à 4 tampon, mais bon autant revenir à 128 2 période.
Aux niveau de la latence c'est blanc bonnet - bonnet blanc.


Pour l'heure en commentant le nice -1 dans le même condition que le premier test 20 minutes sans xrun

pierrotlo utilisateur non connecté Suisse

3.2.0.23-realtime de chez KXstudio

pierrotlo utilisateur non connecté Suisse
Bon sur la machine après une heure, 10 Xruns.
Pas significatif puisqu'il n'y a pas de craquement en sortie.

NB : sur Zynaddsubfx le patch utilisé est "plucked 1" qui est un des plus lourd.
si je met le son par défaut au lancement : 0 xrun.
Et pour l'instant, il ne s'emballe pas.
Pour rappel :
128 - 2 - 48000Hz

Je vais lancer un autre test sur une autre machine, la dualCore (même kernel même config de base).

Si tu souhaite regarder l'installation de base voir

Projet Taliesin

pierrotlo utilisateur non connecté Suisse
Ok test sur le Taliesin :

gestion => Claudia (ladish)
Séquenceur => QmidiArp
Qsynth + le sf2 Crisis 1.7 Gb histoire d'occuper la mémoire
jack-host-dssi + whysynth
Phasex

1 heure sans xruns

l_d_v_c utilisateur non connecté
Je ne connaissais pas /etc/security/limits.d/audio.conf mais les problèmes peuvent venir de là.
Je pense que c'est une bêtise de mettre rtprio 99 car c'est la priorité la plus basse pour le temps réel alors qu'au contraire, on veut la priorité la plus haute acceptable... (entre -20 à -10 )...
Ceci n'engage que moi et ma faible expérience du temps réel.
Je vais libérer /etc/security/limits.conf et paramétrer /etc/security/limits.d/audio.conf pour tester...
Merci.
Ludovic

pierrotlo utilisateur non connecté Suisse
Tests faits et en cours, le rtprio à -10 semble effectivement très efficace.
Le nice -1 n'est pas approprié. Il me met un b*** pas possible.
Par contre je te confirme que le fichier à configurer est bien /etc/security/limits.d/audio.conf.

pour l'heure la machine la moins performante pratiquement le quadri coeur après 4h15 de fonctionnement, ne m'a aligné que 27 Xruns. (Phasex + ZynaddSubFx)
rtprio -10

le Taliesin aprés 3h15 (qsynth sur 2 canaux midi + phasex + whysynth -hôte DSSI) => 1 Xrun.
rtprio -10
C'est excellent.

A noter que a2jmidi est lancé aussi.

Maintenant sur le quadricoeur, je vais modifier le rtprio à -15. Juste pour voir

Bien à toi

pierrotlo utilisateur non connecté Suisse
Lancé à 14h30 128 - 2 -48000Hz (rtprio -15)

Bien à toi{QUOTE}

pierrotlo utilisateur non connecté Suisse

Encore juste une chose : normalement les 96000Hz n'entre pas vraiment en ligne de compte dans le test car ils sont dépendant de la puce DAC (digital analog converter) de ton périphérique son.

Bien à toi

pierrotlo utilisateur non connecté Suisse
Sur le Taliesin

5 heures sans xruns

rtprio -10

pianolivier utilisateur non connecté France
http://linux.die.net/man/2/setrlimit
RLIMIT_NICE
Specifies a ceiling to which the process's nice value can be raised using setpriority or nice

RLIMIT_RTPRIO
Specifies a ceiling on the real-time priority that may be set for this process using sched_setscheduler and sched_setparam.

http://linux.die.net/man/2/sched_setscheduler
sched_setscheduler
Processes scheduled under one of the real-time policies (SCHED_FIFO, SCHED_RR) have a sched_priority value in the range 1 (low) to 99 (high). (As the numbers imply, real-time processes always have higher priority than normal processes.)

en gros, rien à voir entre nice et rtprio, ensuite :

http://lists.linuxaudio.org/pipermail/linux-audio-user/2010-March/067904.html
renice has NEVER been the right way to make audio work. the fact that it happens, in a few cases, to have some beneficial impact has apparently misled some people who don't understand how this all works. nice and renice have absolutely nothing to do with making sure that audio plays correctly. the capability that they represent should not be used for this purpose, and people who spread around patches to limits.conf that include it are simply confusing people with an error.

en gros, si ça fonctionne chez toi, ça n'est pas une raison pour le conseiller à la majorité.

enfin rtprio est lié aussi à la prio de jack dont tu n'as pas parlé. La prio de jack doit être au minimum 10 points inférieure à rtprio, je serai curieux de savoir comment fonctionne les choses chez toi. Tu peux voir les prio à coup de ps (aussi dans la doc ici).

oliv'

Page : 1/2