Skip to main content

4 - Toutes les autres applications, les émulateurs...

Liste des forums Liste des sujets

Forums > 4 - Toutes les autres applications, les émulateurs... > Qsynth + qjackctl + tuxguitar => plantage en cours d'utilisation
 
Thread actions
Print this page
  • Imprimer toutes les pages

    • Qsynth + qjackctl + tuxguitar => plantage en cours d'utilisation

    Envoyé par pavatar le Fri 14 Aug 2015 18:38 Articles: 10
    Bonjour,

    J'utilise pour composer qjackctl pour connecter Qsynth à MidiThrough connecté à tuxguitar.

    Tout fonctionne bien, mais lorsque l'utilisation est un peu longue (ou peut être au bout d'un nombre x de "Play/Pause"),
    Qsynth plante, et même au redémarrage du logiciel, le plantage continue; cela entraîne parfois au même moment un plantage sur Jack (problème DBus?);
    les 2 seules solution qui marche pour reprendre le travail est de se crever les tympans et de se dire que toute façon on est sourd ou bien de redémarrer l'ordinateur. J'opte le plus souvent pour la 2nde solution.

    Dans le strace de Qsynth (après 1er plantage), je vois apparaitre ces lignes parmi d'autres:
    ...
    mlock(0x7f40919a7010, 148196112) = -1 ENOMEM (Cannot allocate memory)
    ...
    connect(12, {sa_family=AF_LOCAL, sun_path="/dev/shm/jack_default_1000_0"}, 110)
    read(...)

    et le programme reste bloqué sur ces instructions.


    Quelqu'un à une idée de se qui se passe ?
    Lectures: 2568
    Envoyé par utilisateur_anonyme2 le Fri 14 Aug 2015 19:17 Articles: 7151
    Salut
    Ça sent un problème configuration pour le temps réel ça non?

    tu tourne sur quoi ? Debian ubuntu ? Si t'es sur ubuntu il te faut le lowlatency et sur debian un noyau rt (real-time)
    ça dit quoi avec ça:

    Copy to clipboard
    ls /etc/security/limits.d

    et
    Copy to clipboard
    groups


    Aussi que dit jack?
    Envoyé par allany le Fri 14 Aug 2015 20:24 Articles: 6259
    Assez d'accord avec utilisateur_anonyme.
    Pour sa première question, poste-nous le résultat de :
    Copy to clipboard
    uname -a

    A+
    Envoyé par pavatar le Sat 15 Aug 2015 21:21 Articles: 10
    Ajoutons que j'ai ce genre de plantage aussi sur Ubuntu Studio, en ce moment j'utilise
    Debian Jessie (8).


    Copy to clipboard
    $ uname -a 
Linux [hostname] 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
$ ls /etc/security/limits.d
audio.conf.disabled
$ groups
[usergroup] cdrom floppy audio dip video plugdev netdev lpadmin scanner bluetooth


    Les messages jack après plantage (je n'arrive pas à avoir un plantage pendant "strace"... ce qui va dans le sens de la théorie d'un problème de synchro)
    Copy to clipboard
    21:09:13.016 Baie de brassage désactivée.
21:09:13.053 Réinitialisation des statistiques.
21:09:13.060 Changement des connexions ALSA.
21:09:13.066 DBUS : le service est disponible (org.jackaudio.service soit jackdbus).
21:09:13.085 Changement des connexions JACK.
21:09:13.089 Client activé.
Cannot lock down 17374362 byte memory area (Ne peut allouer de la mémoire)
Registered event listener change listener:  true

    Envoyé par olinuxx le Mon 17 Aug 2015 13:38 Articles: 19435 France
    Copy to clipboard
    $ ls /etc/security/limits.d
audio.conf.disabled


    Il semble que ton soucis soit ici. Tu n'as pas accès au temps-réel pour les applications (voir PAM pour plusse d'information).

    si tu fais un
    Copy to clipboard
    cat /etc/security/limits.d/audio.conf.disabled
    , tu devrais avoir quelque chose comme cela :
    Copy to clipboard
    # Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
#    dpkg-reconfigure -p high jackd

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19


    Si c'est bien le cas, tu peux faire :
    • te mettre en administrateur, sur Debian :
      Copy to clipboard
      su
    • renommer le fichier pour le mettre en action :
      Copy to clipboard
      mv /etc/security/limits.d/audio.conf.disabled  /etc/security/limits.d/audio.conf
    • tu redémarres et ça devrait être bon

    Dis nous.
    Envoyé par utilisateur_anonyme2 le Mon 17 Aug 2015 20:02 Articles: 7151
    Et pour le RT :

    Copy to clipboard
    $ uname -a 
Linux [hostname] 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux


    Tu le chopera sur le dépot testing ...
    Puis pour pouvoir booter dessus soit tu compile grub-customizer ou bien tu chop un deb tout fait ICI
    Il te faudra gksu et hwinfo pour qu'il puisse fonctionner.
    Envoyé par olinuxx le Tue 18 Aug 2015 10:38 Articles: 19435 France
    Le noyau RT n'est pas nécessaire pour ce cas d'utilisation je pense. @pavatar, tu verras ça par la suite si besoin.
    Envoyé par utilisateur_anonyme2 le Tue 18 Aug 2015 12:18 Articles: 7151
    S'il n'est pas en rt son jack plantera si d'autres ressources sont exploitées non ? (enfin je dit ça mais bon il verra bin )
    Envoyé par olinuxx le Tue 18 Aug 2015 17:29 Articles: 19435 France
    @utilisateur_anonyme : pas forcément. Le noyau RT est de moins en moins nécessaire puisque les améliorations qu'il contient se retrouvent intégrées au noyau normal au fur et à mesure.

    Un noyau basse-latence + rtirq suffit pour les 3/4 des utilisations MAO de nos jours.

    D'après les messages donnés par pavatar, ça flanche car ses applications n'ont pas accès au temps-réel pour les applications. Avec un réglage correct de son PAM, ça devrait le faire.
    Envoyé par pavatar le Thu 10 Sep 2015 00:20 Articles: 10
    Salut ! je n'ai pas eu trop d'occasion de tester, effectivement je constate de plantage depuis que j'ai activer audio.conf. Par contre j'ai audacity qui bug souvent... mais c'est probablement un autre sujet 😛