Bonjour à tous, :)

Je sais bien que mon titre est un peu long mais c'est l'erreur que j'ai lorsque je cherche à utiliser Jack, Pure data et Ardour sous ubuntu 11.04.
Je cherche à savoir ce que cela veut dire. Pour le moment, je n'ai pas trouvé d'explication correspondant à mon cas. Lorsque je lance jack... pas de problème. Lorsqu'ensuite je lance Pure data, je peux avoir quelques xruns dans jack avec ce message dans puredata. Et lorsque je lance ardour, c'est la catastrophe à tel point que tout enregistrement est quasiment impossible. :(

Ce message vous dirait-il quelque chose?
Je vous remercie pour votre aide. :)

erf, ardour je connais tchi' perso...

Merci pour ton intervention, :)

Mais Toulouse est bien en France, si je ne me trompe pas et pourtant je ne comprends pas ton français. Pourrais-tu formuler ton propos d'une autre façon? :/

Désolé, mais je ne comprends pas ce que tu veux me dire. ;)

salut.

c'est quoi tes versions de Ardour, jack et pd ?

est-ce que ca marche si tu lances jack puis Ardour ? (sans pd)

est-ce que tu es membre du groupe 'audio' ?

groups USERNAME

(bien-sûr il faut remplacer USERNAME par ton nom d'utilisateur ;)

tu peux poster le contenu de /etc/security/limits.conf
ou /etc/security/limits.d/audio.conf selon ton système ?

++
_y

Héhé non je voulais dire que ardour j'y connais que dalle... les conseils de {yv} te seront certainement d'une bien meilleure aide

Bonsoir,

Pour les versions :
qjackctl                0.3.7-1
libjack-jackd2-0            1.9.6~dfsg.1-5ubuntu
ardour            1:2.8.11.3
pd-extended        0.42.5-2

Je viens de faire un petit test en démarrant jack puis ardour. J'ai une vingtaine de xruns au départ, mais je pense que c'est parce que j'ai des entrées qui sont paramétrées sur pure data que je n'ouvre pas dans ce test. Ensuite, si je lance la lecture apparemment, je n'ai pas de nouveau xrun et les pistes de ardour sont lues correctement.

Je suis bien membre du groupe audio

Pour /etc/security/limits.conf, voici son contenu

citation :

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - an user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#        - NOTE: group and wildcard limits are not applied to root.
#          To apply a limit to the root user, <domain> must be
#          the literal username root.
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open files
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#        - chroot - change root to directory (Debian-specific)
#
#<domain>      <type>  <item>         <value>
#

#*               soft    core            0
#root            hard    core            100000
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#ftp             -       chroot          /ftp
#@student        -       maxlogins       4

# End of file

@audio - rtprio 99
@audio - memlock 800000
#@audio - nice -10

Je te remercie pour ton attention :)

A Rep: je comprends mieux maintenant . ;)

KaHuZaK a écrit:

Pour les versions :
qjackctl                0.3.7-1
libjack-jackd2-0            1.9.6~dfsg.1-5ubuntu
ardour            1:2.8.11.3
pd-extended        0.42.5-2

mmh, c'est bizarre, j'ai quasi les mêmes versions que toi (à part pd, j'ai pd-vanilla-0.43) et aucun problème ni Xrun.

mon kernel: 2.6.39-ARCH

peut-être la relation entre pd et jackd pose problème, il me semble avoir vu des trucs bizarres à un moment mais je ne suis pas sûr et je ne connais pas du tout pd-extended.

citation :

@audio - rtprio 99
@audio - memlock 800000
#@audio - nice -10

tu as essayé avec un rtprio moins élevé ? qque chose comme:

@audio - rtprio 65

puis logout (ou reboot)...

edit: typo

Bonsoir, :)

Je me suis servi de cette adresse pour paramétrer le limits.conf : http://linuxmao.org/tikiwiki/tiki-index … =applis+RT

Il est vrai que j'y suis allé un peu fort en mettant 99 puisqu'il est conseillé 90. Mais 65 est peut-être un peu faible, non?

En tout cas, je te remercie pour l'idée. Je vais faire quelques essais pour voir ce que ça donne. ;)

A+ :)

C'est déjà moi.

Je m'apprêtais à faire des essais de valeur pour rtprio quand je me suis aperçu que j'ai un fichier /etc/security/limits.conf et un autre /etc/security/limits.d/audio.conf.
Ces deux fichiers contiennent rtprio et ses petits frères. Je me dis que il y a probablement conflit entre les deux et que cela est peut-être la source du problème, mais je ne sais pas quel fichier je dois supprimer.
Je vais donc essayer de supprimer l'un ou l'autre et voir ce que ça donne. ;)

c'est /etc/security/limits.d/audio.conf qui est pris en compte par jackd sur Ubuntu (depuis 2 ans déjà) mais si il y a exactement  la même chose dans les deux (au niveau de l'audio) il n'y a pas de conflit .
quand à affecter une valeur/ une ligne type @nice - value c'est une hérésie selon les développeurs de ardour
sur ma machine

@audio   -  rtprio     99
@audio   -  memlock    2060580

c'est tout .
Je sais pas interpréter le log d'erreur de [puredata] mais çà ressemble à une non concordance de réglages dans tes trois softs . Que te disent les logs de qjackctrl et ardour ?

J'ai donc procédé à plusieurs essais. :)

En premier lieu, si je garde /etc/security/limits.d/audio.conf lorsque je relance la machine, je ne peux plus me connecter. C'est à dire que ubuntu redémarre jusqu'au moment où il est demandé le mot de passe. Et là, je peux le taper 50 fois, le démarrage ne va pas plus loin et je n'ai plus qu'à reprendre un dvd d'install pour monter le disque système et renommer le /etc/security/limits.conf.old en /etc/security/limits.conf. Je rappelle que j'utilise une 11.04 et je viens encore d'aller vérifier à nouveau.

Ensuite je renomme le /etc/security/limits.d/audio.conf en /etc/security/limits.d/audio.conf.old. Je relance la machine. Et là, je vois une nette amélioration. C'est à dire que je démarre Jack et pd. Puis je lance Ardour et je vois encore beaucoup de xruns mais c'est surtout au démarrage de Ardour qu'ils apparaissent. Une fois que celui-ci est démarré ça se calme sérieusement. Et j'ai même fait plusieurs essais d'enregistrement de ma basse en passant par pure data et c'est nickel. Plus aucun cliquetis ou très très peu. :cool:

Je vois encore apparaître le message d'erreur que je cite dans la fenêtre de Pd, mais uniquement au début du démarrage du trio. Après ça ne bouge plus. ;)

Tout cela est d'autant plus étrange que ça va à l'encontre de ce que tu dis, Sakramh, et à l'encontre de ce qui est expliqué à l'adresse que je donne pour le réglage des paramètres pour PAM. Peut-être y a-t-il quelque chose qui m'a échappé. :rolleyes:

Une chose que j'ai remarquée par contre, est que j'ai mis deux zones tableaux, dans Pd, pour imager le signal-son (pour droite et gauche). Ils sont sensés évoluer avec le son, bien évidemment. Mais au bout d'une période de longueur variable, ces tableaux se figent alors qu'ils fonctionnaient très bien quand j'avais commencé ce projet de rack d'effets pour ma basse et que je lançais pure data seul en me servant d'ALSA et non de jack.

Je ferai de nouveaux essais demain et vous tiendrai au courant. Notamment, effectivement, Sakramh, je regarderai de plus près les messages de jack et Ardour pour les reporter ici. ;)

A+ :)

serait-ce un problème lié à "jack2" (jack-smp) ? perso je tourne encore sous jack "1" (et sous 10.04) donc je peux pas vraiment tenter de reproduire le bug . Par contre il me paraît étrange que des modifs des fichiers limits.conf empêchent de se connecter en tant qu'utilisateur . Ce sont des fichiers root . Sinon : mettre une priorité temps réel sur un process (dans les fichiers limits.d) n'a pas vraiment de sens si on n'a pas un kernel "RT" installé .
C'est mon cas mais la machine est une bête et çà passe . Sur un simple bi- processeur çà passerait moins bien .
Essaie aussi d'utiliser jackd en mode NON-temps réel  puisque avec ALSA tu n'as pas de soucis . Accessoirement as-tu PulseAudio d'installé ? .

KaHuZaK a écrit:

Il est vrai que j'y suis allé un peu fort en mettant 99 puisqu'il est conseillé 90. Mais 65 est peut-être un peu faible, non?

ca dépend, sur mon petit proc ca suffit.

sakramh a écrit:

KaHuZaK a écrit:

#@audio - nice -10

quand à affecter une valeur/ une ligne type @nice - value c'est une hérésie selon les développeurs de ardour sur ma machine

cette ligne est commentée chez Kahuzak

sakramh a écrit:

serait-ce un problème lié à "jack2" (jack-smp) ? perso je tourne encore sous jack "1"

perso je considère que c'est une hérésie de continuer à utiliser jackd depuis que jack 2 (jackdmp) existe vu que chez moi ainsi que chez tout le monde que je connais ce dernier est *beaucoup* plus stable (et les xruns ne produisent plus de coupure audio par exemple, ...). ca fait un moment qu'on a abandonné jack 1 =)

sakramh a écrit:

Essaie aussi d'utiliser jackd en mode NON-temps réel  puisque avec ALSA tu n'as pas de soucis

uh ?

@KaHuZak: perso je n'ai absolument aucun xrun (avec 3 cartes son différentes, OSS, usb et firewire). Tu as essayé d'autres paramètres pour jack ? voilà les miens à titre d'exemple:

/usr/bin/jackd -dalsa -dhw:0 -r44100 -p1024 -n3

++
_y

sur ma machine

/usr/bin/jackd -P89 -p128 -m -dalsa -r44100 -p128 -n4 -D -Chw:0 -Phw:0 -zt

le -P89 étant la prio en mode temps-réel
le tout me donnant une latence de 11ms6
c'est clair que les réglages de jack doivent être affinés en fonction de la carte utilisée
jack2 n'est pas dispo pour ubuntu 10.04 donc je n'ai pas comparé . TangoStudio (et d'autres ) le propose (en unstable) pour la 10.04 .

Bonsoir à tous, :)

Je viens de refaire donc des essais. Je confirme que le trio est utilisable avec ces nouveaux éléments dont je parlais hier. Cependant cela reste largement perfectible parce que j'ai encore beaucoup de xruns (mais je suis passé à plus de 1500 à environ 250 pour une demie-heure d'utilisation). J'ai eu deux décrochages audio pendant le même laps de temps de 1/2 heure, aujourd'hui. :)
Je viens de m'appercevoir que j'ai du oublier de donner les caractéristiques générales de mon matos. Je le fais donc maintenant: core i7920, 6Go de ram, ubuntu 11.04 et Edirol UA25.

citation :

@KaHuZak: perso je n'ai absolument aucun xrun (avec 3 cartes son différentes, OSS, usb et firewire). Tu as essayé d'autres paramètres pour jack ? voilà les miens à titre d'exemple:

/usr/bin/jackd -dalsa -dhw:0 -r44100 -p1024 -n3

Modifier les paramètres de Jack, oui je l'ai déjà fait. Et la dernière fois que j'ai voulu augmenter la latence, il y avait un phénomène trop gênant pour jouer. C'est à dire que le son se trouvait vraiment trop décalé entre le moment où je le jouais et le moment où je l'entendais. Donc, pour moi, pas possible d'augmenter la latence. A moins qu'il y ait une astuce que je ne connais pas. Je met une capture de mes réglages actuels.

citation :

Par contre il me paraît étrange que des modifs des fichiers limits.conf empêchent de se connecter en tant qu'utilisateur . Ce sont des fichiers root

Moi aussi d'autant plus qu'à ce stade de l'identification, le son n'est pas encore utilisé. Mais je ne fais que constater. ;)

citation :

Essaie aussi d'utiliser jackd en mode NON-temps réel  puisque avec ALSA tu n'as pas de soucis

Oui c'est un essai que je pourrais faire aussi. Mais ne vais-je pas y perdre, si j'utilise pure-data pour avoir des effets en temps réel, justement?

citation :

Accessoirement as-tu PulseAudio d'installé ? .

Oui, tout un tas de modules d'ailleurs, mais pas celui concernant jack.

citation :

sakramh a écrit:

        KaHuZaK a écrit:

        #@audio - nice -10

    quand à affecter une valeur/ une ligne type @nice - value c'est une hérésie selon les développeurs de ardour sur ma machine

cette ligne est commentée chez Kahuzak

Oui je confirme, elle est commentée et c'est d'ailleurs conseillé si j'en crois linuxmao.

Comme je vois que je n'arrive pas à envoyer la capture, je donne les paramètres à la main:
Prio : 89
Echantillons/Période : 128
Fréq : 44100
Périodes/tampon : 3
Périph entrée/sortie: hw0

trouvé çà : https://answers.launchpad.net/kxstudio/+question/114032 et d'autres en "googlant"
et puis (sous toutes réserves) : tu indiques une ua25 edirol, usb donc, tu es sûr qu'elle soit en hw:0 ? sauf si tu n'as pas de carte interne ou si tu as modifié les index dans alsa-base.conf elle se placerait plutôt en hw:1 .
128 échantillons/période avec 3 périodes par tampons donne 8,71 ms de latence à 44,1, c'est bien . Tu es sûr que 256/3 (17ms) ne te suffisent pas ? (surtout si tu as pas un kernel RT)  . Ou 128/4 qui donne 11ms . Quand aux 3 périodes par tampon c'est mandataire pour beaucoup de cartes firewire (libffado) pour les usb est-ce la solution ?

Salut,

j'ai une ua25 edirol aussi sous ubuntu 10.04

ça marche mieux avec 3 ms par tampon pour l'usb, je confirme.

le numéro de hardware peut changer entre 2 reboots sans logique apparente.

j'essaierais moi aussi avec un "Frames/Period" de 256 ou même 512 ou 1024 juste pour voir si tu as encore des xruns.

quant au nombre de buffers, il me semble que 3 était surtout conseillé pour les chipsets Intel, mais chez moi ca marche nickel avec ma carte USB ou FW.

++
_y

Bonsoir à tous, :)

Je viens encore de faire des tests et j'ai pu me rendre compte qu'il se confirme que même si j'ai encore beaucoup de xruns, je peux jouer et enregistrer ma basse avec une qualité tout à fait acceptable. Ce qui n'est déjà pas si mal, comparé aux piètres résultats que j'avais avant. :cool:

Aujourd'hui j'ai essayé de jouer avec alsa pour moteur de puredata. Ca marche, certes, l'inconvénient est que Ardour demande Jack pour démarrer. Je n'ai pas trouvé le moyen de le lancer avec alsa. Donc, j'abandonne cette solution.

J'ai mis 3 périodes par tampon parce que, autant que je me souvienne, c'est ce que j'ai vu conseillé pour une carte usb sur linuxmao. Pour la latence, je vais faire d'autres essais, mais si c'est comme ce que j'ai déjà vu, celle de 8,71ms que j'ai actuellement est déjà limite pour les raisons que j'ai expliquées.

Bon je ferai d'autres essais, demain. Je vous tiens au jus du progrès accompli.

J'ai remarqué que les xruns apparaissent surtout quand j'ouvre une session dans ardour ou quand je bouge un peu la souris, par exemple. Mais pendant que je fais lire ou enregistrer par ardour, ça se calme.

Il y a aussi que j'ai une vieille 0404 que j'ai désactivée sur la machine. Je pense que je vais la retirer carrément car elle est HS.

A+;)

Bien le "petit détail"   

citation :

ou quand je bouge un peu la souris

celà arrive en effet (surtout avec certaines cartes Nvidia) et signifie que les priorité temps réel ne sont pas vraiment fixées (le serveur X continue de prendre la main) . Tu utilises un kernel RT ? Pour natty des "low-latency" sont dispos ici :
https://launchpad.net/~abogani/+archive/ppa
le kernel low-latency n'est pas vraiment un preempt mais c'est déjà un plus par rapport à un générique .
Avec un vrai RT ( de mémoire les derniers sont des 2.6.37) il faut en plus fixer les priorités grace à un script : rtirq-init (dispo dans les dépôts) et le tweaker selon ses besoins .
10 ms de latence peut à la limite être génant sur des prises de voix ou avec un batteur très pointu, sinon 10 à 20 sont normalement largement suffisants .

Bonsoir à tous, :)

J'ai fait de nouveau des essais en augmentant le nombre d'échantillons par période de 128 à 256. Certes, le nombre de xruns s'en trouve sérieusement diminué, mais ce n'est pas jouable. Le son a un décalage vraiment trop important entre le moment où je le joue sur ma basse et le moment où je l'entends (dans ce cas, la latence passe de 8.71ms à 17.4ms). J'étais habitué à une latence de 4ms avec la 0404 sous Xp. Ca fait un peu bizarre. :/
C'est bien une Nvidia que j'ai.
Egalement, je n'utilise pas de noyau RT, autant que je sache. Je m'apprête donc à réinstaller une ubuntu sur un disque à part, pour éviter toute déconvenue sur le disque actuel. Et je vais tenter l'install d'un tel noyau. Quelques conseils pour l'opération, peut-être? ;)

A+

Salut,

J'ai suivi avec grand intérêt la discussion et j'ai appris beaucoup de chose, merci.;)

Voici un lien qui explique comment installer un noyau rt et même comment le compiler mais là c'est un peu plus compliquer.

http://lprod.org/wiki/doku.php/audio:jack:rt

Il existe une distribution basée sur Ubuntu mais orientée MAO avec un kernel low-latency en 2.6.32 et un real time en 2.6.33 . Et cerise sur le gateau les drivers Nvidia quii vont bien avec .
http://tangostudio.tuxfamily.org/
Avec pas mal d'explications sur le forum pour le tweaker à ses besoins .
Bon c'est basé sur la 10.04 (support à long terme) et pas sur la 11.04 mais le support en sera plus long .
On peut aussi utiliser les dépôts Tango sur une 10.04.1 (sans installer la Tango donc) mais pour de la MAO elle est plutôt bien pensée et inclut plein de softs non dispos chez Ubuntu . À essayer . L'iso est un live DVD pour se faire une idée .

+6738,45 pour tangostudio

il y a aussi la Ubuntu studio mais je trouve Tango plus sympa et efficace. Jamais essayé le live DVD encore. Pour le côté LTS, je trouve ça plutôt intelligent, à l'époque où j'étais en debian instable, le nombre de fois où je n'avais plus de driver nVidia suite à une mise à jour du noyau.

KAHuZak: pourquoi n'as tu pas essayé à un buffer à 3ms? Tu auras un délai qui tombe rond, et manifestement ça aide d'avoir 8ms plutôt que 8 virgule quelque chose

@oli44 . Tu n'avais pas le module "DKMS" installé ? normalement celà évite les recompilations de modules lors de mises à jour .
UbuntuStudio ne fournit pas toujours de Kernel RT en fonction des versions officielles et du fait qu'il n'y a pas de patch RT pour toutes les versions du noyau Linux . http://www.kernel.org/pub/linux/kernel/projects/rt/
le prochain sera le 2.6.37

Bonsoir à tous, ;)

Oli44 : Si, c'est ce que j'ai comme valeur depuis le début 3ms (si tu me parles bien des "périodes/tampon"). Et pour autant, je n'ai pas une valeur ronde pour la latence, c'est à dire 8,71 ms.

Sakramh : je suis en train de graver tangostudio. Il est toujours intéressant de découvrir une nouvelle distrib. J'en avais entendu parler, mais sans y prêter attention.

A+ :)

Bonsoir à tous, :)

Après un bon petit festival de 4 jours à deux pas de chez moi, je me remets sur l'ouvrage.
J'ai installé une tangostudio avec quelques petits soucis dont je parle ici http://codelab.fr/1388.
Ceci étant, je continue mes recherches pour améliorer le fonctionnement de Ubuntu. Et j'ai bien progressé aujourd'hui. J'ai installé le pilote pour Nvidia. Et devinez quoi.... je n'ai plus de message d'erreur dans la fenêtre de pure data et je n'ai presque plus de Xruns. Et tout ça en descendant la latence à 4.35 ms dans QjackCtl. :cool:

Je pense donc que l'on peut dire effectivement que le problème vient bien du pilote vidéo. Je remercie donc Sakramh pour la proposition de piste.

A+ ;)