Chargement...
 
Skip to main content

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


[RÉSOLU] Ardour décroche quand Jack rame trop

Bonsoir à tous & toutes.

Je découvre depuis un certain temps le bonheur de faire de la musique sous Linux, avec l'incomparable Ardour (sur un Divin Ubuntu Studio

Après quelques errements (voir topic ici linuxmao, j'ai convergé vers une configuration hardware basée sur une Presonus FP10 dont je suis ravi.

J'ai quand même un soucis dans quelques cas d'utilisations : J'arrive à numériser mes 5 ou 6 pistes mais quand je stop l'enregistrement, il arrive qu'Ardour me dise dans son petit langage à lui un truc du genre " Jack n'est pas assez rapide" et qu'il a du se deconnecter. Et le reconnnect ne marche pas, je suis bon pour un stop/start de jack, et un rédemarrage d'ardour. 😢 Le bug arrive aussi parfois quand j'ajoute 8 pistes d'un coup à une session vierge. Mais jamais quand je le fais pistes par pistes.

J'ai vraiment l'impression que c'est un problème global CPU, car Ardour occupe plus de 40% du processeur, et jack quasiment 20% (Je suis en freebob, buffer 128 pour 8ms de latences, priorité 60). Cela donne une charge comprise entre 1 et 2, ce qui est sans doute trop pour garder le tempo.

Mon PC, sans être le top du top, est quand même un Athlon 1,8 (pseudos) Ghz, avec 512 Mo de RAM. Il boot en noyau temps réel, avec Gnome mais le minimum d'applications en cours.
J'avais le bug avec Ardour 2.1 standard d'Ubuntu Studio, et je l'ai aussi avec un Ardour 2.3 recompilé sans débug et avec optimisation FPU.

Voila, si quelqu'un à une idée, merci d'avance.
France
Bonjour, 😎

Il est préférable d'augmenter à 256 (voir 512) pour avoir une meilleure marge surtout qu'avec freebob, Ubuntu Studio 7.10 est assez sensible

8 pistes d'un coup, ce n'est pas rien quand même, il faut que le matos suive et il n'y a pas que le processeur qui travaille 😉


Salut.

Merci bluedid29 pour ton conseil. Mais si je passe à 256 ou 512, ma latence dépasse les 8ms, et on entend le décallage quand on reboucle entrées=>sorties en temps réel.
D'ailleurs si quelqu'un sait comment router In_x => Out_x d'une presonus sans passer par Jack, je suis preneur.

Par contre j'ai l'impression d'avoir solutionné mon problème par une approche pingouinesque:
- J'ai recompilé la derniere version de jack en 1.109 (avec fifo sur /dev/shm)
- J'ai recompilé ensuite ardour2.3 avec le max d'optimisation (scons DEBUG=0 DIST_TARGET=i686 FPU_OPTIMIZATION=yes )
- J'ai tuné le disque pour qu'il aille + vite
- J'ai changé la latence de ma carte FireWire

Et là miracle, ardour ne prend plus que 20% du CPU, Jack 15%, et il ne décroche plus (enfin sur la dizaine d'essais que je viens de faire). Je pense que c'est surtout la bonne recompile d'ardour qui fait la différence, mais je n'ai pas le courage de tout recommencer pour vérifier. Je verrais semaine prochaine à notre repete si on tient le recording complet sans bug.

Merci encore à LinuxMao pour cette page qui m'a bien guidé dans la recherche d'optimisation du système.

Yves
France
Yves,

Sur le FP10 tu as un mixer qui te permet de router toutes les entrées vers ta sono et de ne pas entendre la latence que tu peux mettre à 100 ms si ça te chante.

Tu me donnes envie de recompiler Ardour ...


Gilles


Salut Gilles.

Je ne comprends pas ta phrase "Sur le FP10 tu as un mixeur qui permet de router toutes les entrées vers ta sono" , mais cela m'interesse.

En fait je branche les micros chant sur les préamp des entrés 3 & 4 de la FP10. Je recupère ensuite sur les Out 3 & 4, pour les rebalancer vers la table de mixage ou je peux mettre de l'effet, equaliser graves & aigues, compresser, ... avant de les rebalancer vers la sono.
Comme cela, ordinateur éteinds, on peut jouer.

Quand je lance jack, il deconnecte tous les liens in_x => out_x. Du coups je suis obligé avec qjackclt de rebrancher in_3 => out_3 et pareil pour 4. Mais j'ai de la latence.
Comment fait tu pour ne pas l'avoir ?

Yves