Chargement...
 
Skip to main content

1 - La documentation et les nouvelles de LinuxMAO

Liste des forums Liste des sujets

 
Thread actions
Print this page
  • Imprimer toutes les pages

    • [FERMÉ] limits.conf / watchdog

    Envoyé par olinuxx le Tue 27 Jul 2010 18:45 France
    Coucou, de ce que j'ai compris, les nouvelles debian ont changé l'emplacement du fichier limits.conf, du coup, ça va pas tarder à arriver dans les distributions de cette famille (c'est déjà là sur lucid lynx).
    Du coup, je pense qu'il faut centraliser l'info de l'emplacement sur une page et linker à partir des autres pages quand on en a besoin, sinon, ça va être un bordel sans nom à maintenir.
    Du coup, l'idée de JY d'une page dédiée à la 10.04 n'est pas la bonne, mais elle a le mérite d'exister. Je pense plus à un paragraphe dans la page PAM

    Qu'en pensez vous ?
    a+
    Olivier

    PS : les pages que j'ai repéré et qui sont concernées :
    Accès temps réel pour les applications 10_04
    PAM
    Débuter - survol du système
    Tuto Jack premier lancement
    ... il y en a surement d'autres, à vos coms' 😉
    Lectures: 17213
    Envoyé par olinuxx le Fri 03 Sep 2010 17:35 France
    ba ?!?! Je le fais déjà 😬
    J'en laisse un par jour, si j'en édites un qui a déjà été lu, alors, y'a de grande chance que l'édit ne soit pas lu, et du coup, ça sert à rien ...

    Bon, je note la remarque, je vais voir ce que je peux faire. 😉
    de rien😀
    Olivier
    Envoyé par pianolivier le Sat 04 Sep 2010 16:42 France
    avec un noyau "standard" (comme pour toi jy), les périphériques (carte son et timer) ont une priorité innaccessible au dessus de toute application
    donc on ne se pose pas vraiment la question : dans limits.conf : rtprio = 90
    il ne faut pas oublier de mettre une prio plus petite pour jack : -P70

    essaye avec ca jy, ca devrait rouler aussi 😉

    ps : j'ai édité mes posts précédents pour plus de clareté
    Envoyé par pianolivier le Sat 04 Sep 2010 16:48 France
    donc a bien comprendre aussi :

    si vous utilisez un noyau rt, il est plus que conseillé d'augmenter la prio de jack (70), de PAM (90) et des IRQ (au dessus, grace à rt-irq) car sinon vous pourriez experimenter des x-runs et autres problemes
    Envoyé par youki le Sat 04 Sep 2010 21:05
    avec un noyau "standard" (comme pour toi jy), les périphériques (carte son et timer) ont une priorité innaccessible au dessus de toute application
    donc on ne se pose pas vraiment la question : dans limits.conf : rtprio = 90
    il ne faut pas oublier de mettre une prio plus petite pour jack : -P70

    essaye avec ca jy, ca devrait rouler aussi wink

    ps : j'ai édité mes posts précédents pour plus de clareté

    si vous utilisez un noyau rt, il est plus que conseillé d'augmenter la prio de jack (70), de PAM (90) et des IRQ (au dessus, grace à rt-irq) car sinon vous pourriez experimenter des x-runs et autres problemes


    Donc quel que soit le cas faut une prio de jack a 70 et un rtprio dans momits.conf/audio.conf a 90?
    C'est ce qui me semble comprendre en te lisant...

    D'habitude je suis bien avec un noyau RT, RTprio a 99 et prio jack a 80.

    La ca fait quelques jours que je tourne avec ce noyau :

    Copy to clipboard
    Linux geezer 2.6.34-1.dmz.3-liquorix-amd64 #1 ZEN SMP PREEMPT Mon Jul 19 00:52:58 CDT 2010 x86_64 GNU/Linux


    RTprio a 48 et prio jack a 28. Ben ca tourne. J'ai essaye d'enregistrer, 11 pistes depuis hydrogen vers ardour avec quelques plugins sur chaque piste (2 distos + coupe-bas), ca tourne tout aussi bien. J'ai obtenu un x-run au bout de 2:34 min. quand j'ai enregistre deux pistes de guitares avec des plugins en plus des 11 pistes d'hydrogen. Essaye en mixant un peu aussi, pas de problemes.

    Bref, ca tourne pas plus mal qu'avec le noyau RT.
    Envoyé par pianolivier le Sat 04 Sep 2010 22:14 France
    Donc quel que soit le cas faut une prio de jack a 70 et un rtprio dans momits.conf/audio.conf a 90?

    oui, sauf que les utilisateurs du noyau rt doivent faire une manip en plus
    Bref, ca tourne pas plus mal qu'avec le noyau RT.

    c'est clair 😉
    Envoyé par pianolivier le Tue 07 Sep 2010 23:12 France
    je voulais éditer une des pages existantes pour expliquer mieux les IRQ, genre latence (qui regroupe deja quelques infos)
    mais ca me parait maintenant trop ambitieux d'essayer de toucher cette page sans en enlever les 3/4 du contenu, et pour mettre ou ? certains paragraphes sont out-of-date mais d'autres sont encore bon, peut etre...

    du coup, création d'une nouvelle page : Temps-réel pour les processus IRQ qui n'est pour l'instant liée à rien, mais ca viendra plus tard
    je la rempli un peu tous les soirs, tel est le projet, venez donner un coup de patte à l'occase 😉
    Envoyé par olinuxx le Tue 07 Sep 2010 23:36 France
    belle sagesse d'esprit 😉
    Je t'aiderai si je peux, n'hésites pas à demander (genre pour repasser sur les accents derrière toi 😉 )

    a+
    OH !
    Envoyé par jy_moustache le Fri 17 Sep 2010 09:42
    hello

    bon ca n'a pas grand chose à voir mais MERCI BEAUCOUP !!!
    Merci pianolivier d'avoir fait toutes ces recherches qui m'ont enfin permis de rentrer un réglage qui a stabilisé ma machine !
    j'ai longtemps cru que mes xruns était lié à l'architecture de mon hardware, IRQ, interrupts et tout le tralala alors qu'en fait mon limits.conf et ma priorité jack était tout simplement mal réglée !!!

    Hier soir j'ai pu faire tourner seq24, 2 instances de bristol sans AUCUN xruns. une chose impôssible à envisager il y a seulement 3 semaines 😉

    prochaine étape : aller regarder de plus près les IRQ 😉

    jy
    Envoyé par pianolivier le Fri 19 Nov 2010 20:29 France
    voici une copie d'un bout de discute sur #jack :
    pianoliv : Hi there. I was wondering : is jack_watchdog only active when running in real-time mode ?
    las : pianoliv: correct
    las : pianoliv: there is nothing for it do otherwise - a simple ctrl-c will work (for example)
    pianoliv : las, what about the timout setting ?
    las : pianoliv: by default its 1 period
    pianoliv : las, timeout is used at all time ? (rt onr not)
    las : pianoliv: well, the server thread is waiting for (a) all clients to finish (b) some timeout, whichever comes first
    pianoliv : I don't quite understand that, but I guess it answers my question 😊 thanks again las !

    if anyone here gets it, explaination in french would be much appreciated 😉
    ...
    later, las at the rescue :
    las : pianoliv: when the server decides its time to run the clients' process() callback, it starts off the "chain" of clients and then waits for it to complete
    las : pianoliv: JACK does *not* go "server - client1 - server - client2 - server"
    las : pianoliv: instead, it runs things like this: server - client1 - client2 - server
    las : pianoliv: while it waits for client1 & client2 to finish, the server also waits for *some* timeout to expire
    las : pianoliv: normally, you'd expect client1 & client2 (and all the others) to be done on time
    pianoliv : las, ok. I think I am confusing jack timeout and jack watchdog timout. I 'll read more about it
    las : pianoliv: there's not much to read
    pianoliv : Well , i will read that first before taking your time anyway 😊
    las : pianoliv: the watchdog is there to protect against cases where a client ends up in an infinite loop. since its running with RT scheduling, on a uni-processor that will lock up the machine
    las : pianoliv: the watchdog thread runs at an even higher priority, notices the problem, and attempts to kill something to correct it
    pianoliv : las, it is suddently all clearer to me. One last thing though : man jackd says timout is by default 500 ms. why do you say its 1 period ?
    las : pianoliv: the man page is correct
    las : pianoliv: the 1 period wait is what we used to call "ASIO mode"
    las : pianoliv: although its not really related to ASIO at all
    pianoliv : 😊
    pianoliv : las, all of this is going straight to linuxmao.org (linuxDAW in french), thanks for your answers 😊

    Envoyé par pianolivier le Fri 19 Nov 2010 20:34 France
    prochaine étape : aller regarder de plus près les IRQ

    on m'a assuré que la livraison de la documentation sur le sujet est prévue pour le courant de la semaine qui vient. esperont qu'il n'y ai pas de greve des transports.... 😉
    Page: 4/4
    1  2  3  4