3 - Forum dédié à Ardour

Envoyé par calixtus06 le mar. 28 Dec 2021 16:00

[RESOLU] Instabilité générale d'Ardour

Envoyé par calixtus06 le mar. 28 Dec 2021 16:00

Hello,

Depuis quelques temps une série de problèmes vient s'accumuler dans mon ardour 6/ librazik3. Est ce du à des soucis de mise à jour, de noyau, d'ordi , de réglages, de carte son ?
__
Quelques symptômes: __

Je me suis retrouvé avec le son qui disparaissait dans plusieurs session. Le son est "visible" : trace sur le séquenceur, les jauges de volumes et jack réglé, mais pas de son ..Je duplique des pistes mais le son est nul part pour cette nouvelle piste . Idem avec un jack vérifié

Des enregistrements qui s'arrêtent subitement, se bloquent

Ardour crash de plus en plus .

Cela continue : jack est lancé mais ardour ne se branche pas à lui. Je dois donc sans arrêt les reconnecter : fenêtre>connection audio > jack. Ardour plante encore et encore. Désolé , je ne veut pas pourrir l'ambiance. Est ce l'ordi qui lâche ? Un disque dur trop plein par endroit ?

Je test le live de Librazik : même soucis d'instabilité mais ne concernant que le duo jack ardour (par exemple , je ne parviens plus à mettre l'horloge en syncho avec jack)

Côté noyau : le noyau est le Linux librazik3 5.4.0-0.bpo.4-lzk-bl-amd64 #1 SMP PREEMPT Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux

Dans l'IRC il m'a été dit qu'il était ancien mais dans synaptic c'est le plus récent proposé. Est ce du à un soucis de dépôt ?

Paradoxalement (pour moi) le 4.19 est plus récent que le 5.4 de LZK en basse latence (bl).

Comment voir si le problème est général faisant suite à une mise à jour, un changement de noyau ? Est ce que je risque quelque chose à désinstaller ardour pour le réinstaller ? ..si ça en vaut la peine ?

j'ai regardé l'état des condensateurs. Aucun n'est gonflé. j'ai changé la carte son de port usb..

Je sèche

merci d'avance

Nico

Envoyé par calixtus06 le mer. 29 Dec 2021 11:56 · Envoyé par calixtus06 le mer. 29 Dec 2021 11:56 commentaire supprimé

Envoyé par calixtus06 le mer. 29 Dec 2021 11:56

commentaire supprimé

Envoyé par calixtus06 le ven. 31 Dec 2021 01:39 · Envoyé par calixtus06 le ven. 31 Dec 2021 01:39 commentaire supprimé

Envoyé par calixtus06 le ven. 31 Dec 2021 01:39

commentaire supprimé

Envoyé par olinuxx le ven. 31 Dec 2021 13:21

Envoyé par olinuxx le ven. 31 Dec 2021 13:21

@calixtus06 : je vois que tu as effacé 2 messages et ne peux donc pas les lire. Quant à ton premier message, il y a beaucoup de choses sans forcément qu'elles aient un rapport entre elles. Alors je vais te poser une question : que cherches-tu à faire/corriger et où en es-tu ?

Envoyé par calixtus06 le sam. 01 Jan 2022 21:29

Envoyé par calixtus06 le sam. 01 Jan 2022 21:29

Hello !

Si je devais reformuler ma demande d'aide ce serait : comment envisager cette accumulation de problèmes dans ardour ?
Effectivement il y a des problèmes qui appartiennent à des soucis de réglages et d'autres peut-être plus profond. Le symptôme le plus problématique c'est que ardour s'arrête subitement d'enregistrer ( un zèbrage apparaît alors sur la région) ou crashe sans message d'erreur.

Envoyé par calixtus06 le lun. 03 Jan 2022 17:55

Envoyé par calixtus06 le lun. 03 Jan 2022 17:55

Aujourd'hui encore ce message :

Et l'impossibilité de synchroniser ardour et jack ( horloge)

Envoyé par milarepa le mar. 04 Jan 2022 13:31

Envoyé par milarepa le mar. 04 Jan 2022 13:31

Concernant le dernier message, il semblerait que soit le hardware n'arrive pas à suivre le débit, soit le buffer du disque n'est pas assez grand. Je ne sais plus où l'on règle les I/O des disques. Sur quel type de disque sont stockées tes données Ardour ?

Comment as-tu conclu à "l'impossibilité de synchroniser ardour et jack ( horloge)" ? Message dans Ardour ? Dans Jack ? Dans les logs ?

Envoyé par olinuxx le mar. 04 Jan 2022 23:47

Envoyé par olinuxx le mar. 04 Jan 2022 23:47

Citation :

Si je devais reformuler ma demande d'aide ce serait : comment envisager cette accumulation de problèmes dans ardour ?

Il est peu probable qu'il y ait une cause commune à plusieurs soucis si différents que tu rencontres. J'ai plutôt l'impression que puisque tu ne sais pas comment les résoudre ni les uns, ni les autres, ton cerveau (par un biais de facilité) aurait bien envie de découvrir une SEULE et unique cause, pour tout régler d'un coup, et hop, ça ferait des chocapics !

Comme te le dis @milarepa ci dessus, le problème défini dans l'image suivante :

a habituellement pour origine un support qui n'écrit pas assez vite pour ardour.

Les bandes zébrées, c'est quand ardour ne retrouve plus les données d'une région audio et/ou MIDI il me semble. On peut facilement imaginer ici que si le disque dur n'arrive pas à suivre et que les données ne sont pas inscrites, alors ensuite, il ne les retrouve pas.

Envoyé par calixtus06 le mer. 05 Jan 2022 15:48

Envoyé par calixtus06 le mer. 05 Jan 2022 15:48

milarepa écrit :

Concernant le dernier message, il semblerait que soit le hardware n'arrive pas à suivre le débit, soit le buffer du disque n'est pas assez grand. Je ne sais plus où l'on règle les I/O des disques. Sur quel type de disque sont stockées tes données Ardour ?

Comment as-tu conclu à "l'impossibilité de synchroniser ardour et jack ( horloge)" ? Message dans Ardour ? Dans Jack ? Dans les logs ?

Salut, j'utilise un seul SDD EVO 500

Lorsque désormais je clique sur l'icone de synchro dans ardour, je n’obtiens plus jack mais une autre horloge (je préciserai ça plus tard, je ne suis pas chez moi) Je dois retourner dans préférences>transport et remettre jack.

Pas mal d'éléments convergent vers un disque dur qui aurait des lenteurs j'ai l'impression..

Faut il que je vide le cache avant utilisation d'ardour ?

sync; echo 3 > /proc/sys/vm/drop_caches

Envoyé par milarepa le sam. 08 Jan 2022 06:09

Envoyé par milarepa le sam. 08 Jan 2022 06:09

J'imagine qu'il s'agit d'un SSD Samsung 8x0 500GB. Normalement, ce genre de disque est une vraie bombe question i/o. Il faudrait faire un benchmark. Le plus simple consiste à faire un

dd bs=8M count=256 if=/dev/zero of=/tmp/test.tmp

J'écris ce message sur un vieux netbook Acer Aspire One équipé d'un céléron, auquel j'ai mis un SSD EVO 860. C'est une vraie brouette et sur cette machine, ça donne :

milarepa:~$ dd bs=8M count=256 if=/dev/zero of=/tmp/test.tmp
256+0 enregistrements lus
256+0 enregistrements écrits
2147483648 octets (2.1 GB, 2.0 GiB) copiés, 9.54576 s, 225 MB/s

Je peux faire le même test dans la journée sur une machine plus récente.

Autrement, pour mieux connaître les performances du disque, on peut utiliser Bonnie. Mais attention ! Ne pas l'utiliser en root, c'est dangereux (c'est dans la doc).

Envoyé par milarepa le sam. 08 Jan 2022 06:10

Envoyé par milarepa le sam. 08 Jan 2022 06:10

Je ne pense pas qu'il soit utile de vider le cache avant d'utiliser Ardour. Je ne l'ai jamais fait.

Envoyé par milarepa le sam. 08 Jan 2022 10:57

Envoyé par milarepa le sam. 08 Jan 2022 10:57

Voilà le même test avec la machine que j'utilise pour Ardour :

hermes:~$ dd bs=8M count=256 if=/dev/zero of=/tmp/test.tmp
256+0 enregistrements lus
256+0 enregistrements écrits
2147483648 octets (2.1 GB, 2.0 GiB) copiés, 0.858604 s, 2.5 GB/s

On voit qu'entre une machine de 12 ans d'âge et une machine moderne, même si toutes les deux ont des SSD assez proches (Samsung 860 EVO 500G d'un côté et 970 EVO 1TB de l'autre), les résultats sont très différent (225 MB/s et 2.5 GB/s) suivant le hardware qu'il y a autour du disque.

Pour comprendre ton problème, on a besoin de connaître le type de processeur, la quantité de mémoire vive, l'espace libre sur le disque. Éventuellement un free -h quand tu as un problème pour connaître l'état de la mémoire et savoir si tu vas dans le swap (ce n'est pas possible avec ce genre de logiciel).

Envoyé par calixtus06 le mar. 11 Jan 2022 19:03

Envoyé par calixtus06 le mar. 11 Jan 2022 19:03

Hello !!

dd bs=8M count=256 if=/dev/zero of=/tmp/test.tmp

256+0 enregistrements lus
256+0 enregistrements écrits
2147483648 octets (2,1 GB, 2,0 GiB) copiés, 3,24636 s, 662 MB/s

Pas bon signe, non ?

lscpu

Architecture :                          x86_64
Mode(s) opératoire(s) des processeurs : 32-bit, 64-bit
Boutisme :                              Little Endian
Tailles des adresses:                   36 bits physical, 48 bits virtual
Processeur(s) :                         4
Liste de processeur(s) en ligne :       0-3
Thread(s) par cœur :                    1
Cœur(s) par socket :                    4
Socket(s) :                             1
Nœud(s) NUMA :                          1
Identifiant constructeur :              GenuineIntel
Famille de processeur :                 6
Modèle :                                42
Nom de modèle :                         Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
Révision :                              7
Vitesse du processeur en MHz :          2870.208
Vitesse maximale du processeur en MHz : 3400,0000
Vitesse minimale du processeur en MHz : 1600,0000
BogoMIPS :                              6186.12
Virtualisation :                        VT-x
Cache L1d :                             32K
Cache L1i :                             32K
Cache L2 :                              256K
Cache L3 :                              6144K
Nœud NUMA 0 de processeur(s) :          0-3
Drapaux :                               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts

free -h

total        used        free      shared  buff/cache   available
Mem:          6,7Gi       1,5Gi       213Mi       215Mi       5,0Gi       4,7Gi
Swap:         6,9Gi          0B       6,9Gi

df -h

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               3,4G       0  3,4G   0% /dev
tmpfs              685M    9,3M  676M   2% /run
/dev/sda1          451G    245G  183G  58% /
tmpfs              3,4G    148M  3,2G   5% /dev/shm
tmpfs              5,0M    4,0K  5,0M   1% /run/lock
tmpfs              3,4G       0  3,4G   0% /sys/fs/cgroup
/dev/loop0          56M     56M     0 100% /snap/core18/2253
/dev/loop2          66M     66M     0 100% /snap/gtk-common-themes/1515
/dev/loop3         100M    100M     0 100% /snap/core/11798
/dev/loop4         128K    128K     0 100% /snap/bare/5
/dev/loop1          56M     56M     0 100% /snap/core18/2246
/dev/loop5         100M    100M     0 100% /snap/core/11993
/dev/loop6          66M     66M     0 100% /snap/gtk-common-themes/1519
/dev/loop7         165M    165M     0 100% /snap/gnome-3-28-1804/161
/dev/loop8         163M    163M     0 100% /snap/gnome-3-28-1804/145
tmpfs              685M     20K  685M   1% /run/user/1000

Envoyé par milarepa le jeu. 13 Jan 2022 21:03

Envoyé par milarepa le jeu. 13 Jan 2022 21:03

Désolé, j'ai quelques problèmes de santé et je ne me connecte pas souvent sur le réseau.

Bon, tu as un processeur honnête, un i5 4 coeurs. Tu as 8G de RAM ce qui me semble suffisant. Tu n'utilises pas le multithreading ce qui est positif, je pense.

Il y a bien ces 662 MB/s pour l'écriture, cela me semble un peu mou, surtout pour du SSD. Mais je ne pense pas que ce soit ton problème. J'ai fait tourner Ardour sur une vieille machine avec un i3 qui, pour le même test que tu as fait, donne 90.1 MB/s en écriture. Je n'ai fait que de l'audio, pas de MIDI sur cette machine, il y avait une grosse latence mais ça ne plantait pas.

A part ça, mon frère a un vieux portable sur lequel les dernières versions d'Ubuntu étaient inutilisables. J'ai complètement viré snap (qui ouvre tous ces /dev/loopN) et la machine fonctionne maintenant de façon satisfaisante. Il semble que snap bouffe beaucoup de ressources (affirmation intuitive, pas scientifique).

Il m'est difficile de t'aider à partir de là sans mettre les mains dans la machine.

Envoyé par calixtus06 le ven. 14 Jan 2022 11:05

Envoyé par calixtus06 le ven. 14 Jan 2022 11:05

Bonjour à toi milarepa et encore merci de te pencher sur ce problème . J'ai ouvert un autre fil

forumthread107827

qui, il me semble , vient éclairer celui ci dessus.

La vitesse du ssd reprend de la vitesse si j'ai bien compris mais pas à ses pleines possibilités

Quant aux paquets snap et flatpack effectivement il prennent beaucoup de place et j'aimerais trouver des alternatives mais c'est un autre sujet

Envoyé par sub26nico le lun. 21 mars 2022 16:48

Envoyé par sub26nico le lun. 21 mars 2022 16:48

du nouveau ici calixtus06 ?

3 - Forum dédié à Ardour

[RESOLU] Instabilité générale d'Ardour

Documentation

Faire un don

Connexion

Mégaphone