Chargement...
 
Skip to main content

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

Liste des forums Liste des sujets

Forums > 1 - Le matériel et les pilotes ALSA, FFADO, ... > [RÉSOLU] Vos expériences: Edirol FA-101 avec FFADO
 
Thread actions
Print this page
  • Imprimer toutes les pages

    • [RÉSOLU] Vos expériences: Edirol FA-101 avec FFADO

    Envoyé par BlindeKinder le Wed 03 Dec 2008 17:20 Suisse
    Salut, comme les Edirol en Firewire (FA-66 et FA-101) sont réputée désormais pour fonctionner avec FFADO, on ne trouve plus grand chose sur le sujet...
    Comme personnellement j'ai toujours de nombreux problèmes, je voulais connaitre vos expériences, vos réussites et vos doutes...

    Pour moi:
    Ubuntu Studio 8.04 64bit/Edirol FA-101 /AXXIV NG12 proc T9500 2.5GHz 4Go RAM/FFADO RC1
    -Je descend facilement à une latence de moins de 10ms sans pour autant que tout reste bien stable...
    -J'ai atteint une limite de stabilité avec une session Ardour de 55minutes et une vingtaine de pistes avec une config 1024/3...
    -Ardour plante souvent à l'export, indépendamment du poids de la session...
    -Rezound est inutilisable en dessous de 2048/3, et encore, j'ai quelques xruns
    -C'est un ordi relativement puissant, mais je suis à 10% de CPU au lancement de Jack
    -Je n'utilise pas beaucoup les autres programmes, mais le tout reste relativement instable (plantage de Jack sans raisons apparentes etc...)

    Bref, j'adore le système, mais c'est rude parfois, surtout en utilisation "sur le terrain" quand rien ne va et que dix personnes vous stressent derrière... mais je ne lache pas le libre pour autant (j'adore les nuits blanches😉)
    Bon, à vous... 😎
    Lectures: 4070
    Envoyé par jdlv le Wed 03 Dec 2008 18:19
    Bonjour,

    je suppose que le kernel est un vrai rt?
    Ffado fonctionne sans mais peut planter de temps à autre...
    Quel est le modele du chipset firewire? Certains sont carrément inaptes à une utilisation audio, d'autres ne sont pas terribles... lspci dans un terminal dira tout.
    Quelle version de Jack utilises tu? Celle livrée depuis quelques temps dans les distributions est terriblement buggée!
    Jack est il bien lancé avec la priorité rt?
    10% de CPU ne sont pas inquiétants, la gestion du firewire dans le kernel n'est pas des plus performantes.

    Bonne nuits blanches!
    Envoyé par bluedid29 le Thu 04 Dec 2008 02:33 France
    Bonjour, 😎

    Pourquoi absolument utiliser FFADO ? Freebob fonctionne très bien, j'utilise aussi ma FA66 sous Ubuntu Studio 8.04 et j'enregistre plusieurs pistes audio + effets sans trop de soucis sous Ardour 2.7 (latence 16ms).

    Par contre, pour n'avoir absolument aucun soucis, j'ai aussi installé 64 Studio 2.1 en dualboot sur TOUS mes ordis et il m'arrive parfois d'enregistrer sur cette distribution "béton" (mais un peu rustique quand même 😂).

    J'attend que FFADO soit bien achevé, tant que Freebob fonctionne... 😉

    C'était juste un avis perso, j'enregistre quasiment tous les jours avec différentes cartes, donc à force... 😊
    Envoyé par BlindeKinder le Thu 04 Dec 2008 13:12 Suisse
    Bonjour,

    Bonjour...
    je suppose que le kernel est un vrai rt?

    oui, le 2.6.24-22-rt sauf erreur (de la dernière maj Ubuntu Studio)
    Ffado fonctionne sans mais peut planter de temps à autre...
    Quel est le modele du chipset firewire? Certains sont carrément inaptes à une utilisation audio, d'autres ne sont pas terribles... lspci dans un terminal dira tout.

    0e:06.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)
    Je comptais acheter un FW en PCI-E... un conseil? Là j'ai un mini...

    Quelle version de Jack utilises tu? Celle livrée depuis quelques temps dans les distributions est terriblement buggée!

    La dernière SVN...
    Jack est il bien lancé avec la priorité rt?

    bien sûr... rt, priorité 70

    10% de CPU ne sont pas inquiétants, la gestion du firewire dans le kernel n'est pas des plus performantes.

    Sur mon fixe, quand j'utilisais freebob, il me semble que c'était bien au dessous, et l'ordi était bien moins puissant...

    Bonne nuits blanches!

    Merci... Je vais en tout cas voir pour le port FW... Pour la tour, j'avais acheté un contrôleur bien compatible et ça allait bien... remarquons tout de même pour se rassurer que la carte n'a jamais fonctionné avec W$ XP...

    =>bluedid29
    J'avais autant de bugs avec freebob, et je compile FFADO depuis la Bêta6... maintenant on en est à la RC1, et le projet commence à être bien abouti... Il existe même des .deb et des dépôts...
    J'ai installé également 64Studio, mais je n'ai jamais réussi à voir le bureau: il ne reconnait pas ma carte graphique... j'ai abandonné. Mais j'aime bien Musix... j'ai un peu traduit pour eux... Disons que l'ensemble de US est plus stable dans l'ensemble de la distrib, même si musix à plus de programme.
    Envoyé par jdlv le Thu 04 Dec 2008 14:15
    Essaye vraiment de trouver un port firewire équipé d'une puce Texas. Je sais c'est pas facile, rarement indiqué dans les jolies publicités des fabricants!
    Regarde ici :
    http://www.ffado.org/?q=node/251

    Cela peut sembler étrange mais pour jack une priorité de 70 est trop élevée. Pour ffado 45 est une meilleure valeur. L'idée est que le thread de jack qui cause avec la carte son ait une priorité inférieure a celle de l'interruption de la carte son mais supérieure a celles de la tribu des interruptions logicielles ( softirq) et que la priorité des autres threads de jack soit inférieurs a celles des softirq.
    Mais dans ton cas pas sur que cela change grand-chose!

    Avec les dernières versions de ffado, 2 interfaces chainées (fa101 + focus sapphire), 2 sessions d'Ardour, 4 de jconv (convolueur utilisé en reverb) et tous mes efforts déspérés (compilation, firefox, openoffice, installation de packet...), aucuns xruns sur une période de 24H avec un réglage de 3 buffers de 128 échantillons à 44K1.
    Ffado peut faire mieux, mon portable non. L'irq du firewire est partagée avec la moitié des irq de la machine dont la carte graphique!

    Bluedid,
    le problème de freebob est qu'il "oublie" de signaler certains Xrun. Plus ou moins fréquents suivants les machines et peu ou pas audibles mais les coupures sont bien la....
    Envoyé par BlindeKinder le Thu 04 Dec 2008 15:16 Suisse
    merci pour ces infos 😀
    j'étais justement en train de faire les démarches pour une E-card FW... J'ai trouvé ça, qu'en pensez-vous?

    Pour la priorité à 70, je crois avoir lu ça dans les recommandations de config, je crois même sur le site de FFADO... mais je veux bien essayer autre chose...
    Envoyé par bluedid29 le Thu 04 Dec 2008 15:51 France
    Ok BlindeKinder, je ne savais pas que tu suivais d'aussi près l'avancement de FFADO 😉

    Pour les cartes Firewire, c'est un peu la jungle, je te conseille d'acheter une carte dans un magasin ou il est possible de se la faire rembourser car tant que l'on a pas essayé.... (le matériel évolue trop vite malheureusement 🙄).

    Mais ton moteur de recherche est ton ami ! 😂
    Envoyé par BlindeKinder le Sat 06 Dec 2008 15:30 Suisse
    J'ai acheté ça...
    ça marche bien, je vois surtout une différence quand je lance Jack/FFADO en ligne de commande avec -v4 (verbose niveau 4): les infos défilent 10x plus vite...
    J'ai enregistré avec Ardour en latence 2,5 (128/3)... tout de même une plantée (Ardour à "quitté inopinément") et quelques xruns... Ça m'étonne avec une seule piste...
    quant aux autres programmes, ils me font plein de xruns tout de même...
    Envoyé par BlindeKinder le Tue 27 Jan 2009 18:13 Suisse
    Bon, resalut, reproblèmes... 😢
    J'ai réinstallé Ubuntu Studio en 32 bits, réinstallé tous les jack ffado etc...
    Bon, dans l'ensemble ça fonctionne, mais j'ai quelques soucis: dans le meilleur des cas, un xrun de temps à autres, mais le plus souvent un plantage...
    Alors j'ai relu la page Autres Optimisations, et j'ai constaté que j'avais mon express card sur l'IRQ 7 (prio la plus basse...) et partagée avec la caméra, le lecteur d'empreinte, et le bluetooth... rien que ça... J'ai tenté des démarrage avec noapic nolapic (qui me supprime des blocages gênant au démarrage), OHCI (qui ralentit le démarrage): finalement je suis resté sur le moins pire: noapic nolapic / pas d'ahci (désactivé dans le bios)...
    bon, je vous poste un extrait des résultats de lscpi -v / hdparm -Tt / sortie de jack en fonctionnement
    avec noapic nolapic acpi_irq_balance (-ahci conf):

    [+]

    noapic nolapic: (+ahci conf)

    [+]

    hdparm -Tt: ahci conf:
    Copy to clipboard
    Timing cached reads:   9524 MB in  1.99 seconds = 4783.18 MB/sec
 Timing buffered disk reads:  244 MB in  3.01 seconds =  81.04 MB/sec
Jack:
load = 1.9827 max usecs: 480.000, spare = 22739.000
load = 2.0939 max usecs: 512.000, spare = 22707.000
load = 2.2529 max usecs: 560.000, spare = 22659.000
load = 2.1622 max usecs: 481.000, spare = 22738.000
load = 1.9920 max usecs: 423.000, spare = 22796.000
load = 1.9241 max usecs: 431.000, spare = 22788.000
load = 1.9720 max usecs: 469.000, spare = 22750.000
load = 2.1101 max usecs: 522.000, spare = 22697.000
load = 2.1296 max usecs: 499.000, spare = 22720.000
load = 2.0123 max usecs: 440.000, spare = 22779.000



    noapic nolapic (-ahci conf):

    Copy to clipboard
    hdparm -Tt
 Timing cached reads:   10742 MB in  1.99 seconds = 5393.38 MB/sec
 Timing buffered disk reads:  192 MB in  3.02 seconds =  63.58 MB/sec


    [+]

    noapic (-ahci conf):

    Copy to clipboard
    hdparm -Tt
 Timing cached reads:   9874 MB in  2.00 seconds = 4942.01 MB/sec
 Timing buffered disk reads:  244 MB in  3.01 seconds =  81.16 MB/sec




    [+]

    [+]

    rien de spécial (-ahci conf)
    BLOCAGES!!!!
    Copy to clipboard
    Timing cached reads:   9966 MB in  1.99 seconds = 5003.47 MB/sec
 Timing buffered disk reads:  244 MB in  3.02 seconds =  80.76 MB/sec



    [+]

    si vous avec une soluce ou une piste, sympa... sachant que j'ai un portable (donc pas de changements de slot), évidemment pas de menu IRQ dans le bios...
    Envoyé par BlindeKinder le Tue 03 Feb 2009 16:36 Suisse
    Vraiment personne ne s'amuse avec ses IRQ?
    Je galère, le travaille deviens impossible: la connexion/changement de point wifi me fait planter jack (vous allez me dire que je n'ai cas le désactiver, mais là je fais de la numérisation de K7 en temps réel, et faut bien passer le temps, réel ou pas...), j'ai des xruns à chaque fois que je connecte ou déconnecte un pérfif usb, il plante parfois quand je lance certaines applications, ou sans raison, en général quand j'ai décidé de m'éloigner de plus de 10 mètres de l'ordi.... sans parler de la mise en veille, du plantage quand je quitte Pure Data, le freeze complet de l'ordi quand je fais une export sur ardour... Je sais que le son avec linux en est à ces début, mais là ça fait beaucoup... 👻
    Envoyé par Samuel le Tue 03 Feb 2009 20:43 Allemagne
    Salut,

    bon, juste un petit retour d'utilisation.

    Bien qu'aillant une carte FW TI (donc compatible) avec la version actuelle des noyaux rt (2.6.24.xx) je rencontre des incompatibilités (je peux utiliser ma FA101 qu'en capture only). Le problème a été résolu avec la version 2.6.26 du kernel. (enfin normalement, si un jour j'arrive à compiler un noyau 2.6.26 rt correctement).

    Je pense que le soucis viens plus d'incompatibilités lors de la compilation du noyau et qu'il faudrait que tu t'en fasses un "aux petits oignons" sans rien d'inutile. À mon avis ça résoudra tes soucis. De ce que j'en ai vu sur le net, les IRQ sont souvent accusés de tous les maux (et c'était surement le cas avant) mais ne devraient plus être un problème à présent. Je pense qu'une bonne compilation devrait résoudre beaucoup de problèmes.

    Une solution plus facile à mettre en oeuvre serait de voir si ça marche mieux en réduisant la valeur "latency_timer" de tes périphériques pci (controleur firewire ou cardbus bridge par exemple) comme indiqué sur cette page dans les optimisations.

    En espérant que ça aide...
    Envoyé par BlindeKinder le Tue 03 Feb 2009 21:18 Suisse
    Oui, j'ai lu que c'était plus vraiment ça le problème... J'ai essayé le latency_timer, et il me semble pas que ça aie vraiment aidé... mais comme c'est vrai que c'est facile à mettre en oeuvre, je peux retenter... Sinon, j'avoue que la compile du Kernel ça me fait un peu peur... Mais je m'y plonge dès que j'ai le temps, et je donne des nouvelles.
    En même temps, même si GNU/Linux n'aspire pas à un système "prêt à l'emploi mais qui sont pas vraiment optimisé", comme d'autres, je trouve un peu dur toute les magouilles qu'on doit effectuer pour arriver à un peu de stabilité et de performances... Tout mes collègues musicien-ne-s sont charmés par jack tous les logiciels son libres, mais je ne peux pas non plus leur promettre que ça fonctionnera sans autres s'ils font le grand pas: personne ne se lancera pour compiler un kernel, c'oest déjà trop pour certains de taper trois commandes ou d'éditer un fichier pour modifier des configs.... Enfin, j'ai fait ce paris, j'assume, et c'est enrichissant...
    Envoyé par allany le Wed 04 Feb 2009 06:08
    Salut,

    Je prends le fil en cours de route et je vois que vous évoquez des soucis par rapport aux IRQ.
    Sur ma 64studio, je ne peux travailler correctement et sans danger pour mes disques, après avoir galéré des mois, que depuis que j'ai donné à ma carte-son le latency-timer le plus élevé et ...coupé la connection wifi.
    J'ai mis ces deux options en dur dans le startup de Jack et je restaure au shutdown du même Jack. Donc, lorsque je traite de l'audio, la machine est totalement dédiée. Seul inconvénient, Jack est un peu long pour s'arrêter.
    Ne me demandez pas pourquoi mais une impulsion sur le réseau me plantait toute la config avec redémarrage sauvage et check des disques obligatoire. Je crois que certains ont eu le même type de blème avec leurs cartes video, d'ailleurs.
    Ceci dit, c'est un PC tower, pas très puissant et tout ça n'a peut-être pas de rapport...
    Bon courage !
    Envoyé par Samuel le Wed 04 Feb 2009 19:31 Allemagne
    Salut BlindeKinder,

    je comprends bien ta réaction. La compilation du kernel fait peur, et on n'arrive pas toujours au résultat voulu. Et puis à partir d'un moment on a envie de faire de la musique sans avoir le stress d'un système un peu foireux...
    J'en suis a peu près au même point que toi, donc je compatis. J'espère que tout ça va bientôt s'améliorer.
    Envoyé par BlindeKinder le Thu 05 Feb 2009 12:22 Suisse
    => allany: bien, j'ai mis les latency timer en dur, dans /etc/rc.local (script de démarrage)... Mais j'ai toujours les mêmes problèmes, et je ne descends pas plus bas que 2-3ms, et avec des tonnes de xruns... Vous allez me dire que c'est déjà pas mal, mais en achetant mon portable il y a quelques mois, je lui ai collé les meilleures options: T 9500, 4Go RAM, etc... donc je suis un peu déçu de ne pas arriver à ce que décrit jdlv un peu plus haut...
    Si vous connaissez un peu les histoires de latency_timer, vous pourrez peut-être m'éclairer sur le fait que j'ai deux périf dans lspci:

    [+]

    J'ai mis le bridge en sec_latency_timer au max, mais je sais pas si j'ai bien fait... Tous les autres périf sont à 0...

    =>Samuel: Tu résume parfaitement ce que j'éprouve en ce moment!!! 😕
    j'hésite à essayer une autre distro, un peu plus éprouvée qu'Ubuntu niveau stabilité, genre CCRMA ou 64Studio (mais en 32, Pure Data n'aimant pas du tout le 64bit)... un conseil?
    Envoyé par jdlv le Thu 05 Feb 2009 13:45
    Bien possible que le matériel soit trop récent pour le kernel...
    Avant de tout changer essaye le kernel 2.6.28 d'ubuntu jaunty. Il n'est pas patché pour le temps réel dur donc en attendant la disponibilité du patch il te faudra rester raisonnable du coté de la latence mais tes soucis de blocage devraient disparaître.
    Envoyé par Ejis le Thu 05 Feb 2009 14:10
    Salut,

    le patch RT pour le 2.6.28 est actuellement en Release Candidate. Un kernel 2.6.26.8-rt16 est prévu pour rajouter quelques patch issus du futur kernel, et normalement, la branche 28 devrait prendre ses fonctions courant février, je l'espère.
    Ce qui signifie que la prochaine Ubuntu Studio devrait à nouveau fournir un kernel RT (pour les utilisateurs d'Ubuntu).

    Sinon, je ne recommande pas la 26-rt15, car il y a des freeze avec des logiciels comme minicomputer, DSSI ou Rakarrack. Je leur ai signalé sur la ML, mais ça n'a pas l'air de les émouvoir... Pourvu que le rt16 règle ça, parce que ça fait tache.
    Envoyé par BlindeKinder le Thu 05 Feb 2009 16:14 Suisse
    bien, ça motive tout ça!!! 😀 effectivement, je n'ai pas installé Intrepid Studio à cause du rt... en fait j'avais essayé mais je n'avais même pas d'écran, car apparemment les modules graphiques n'étaient pas présent...
    C'est hallucinant comme il y a des bugs réglé à chaque version du kernel (mais malheureusement à chaque fois des nouveaux également )... Intrepid (version normale) m'a réglé ces problèmes de blocages d'ailleurs...
    bon, j'attends Jaunty. J'ai d'ailleurs lu que le développement a été axé sur la stabilité plus que les nouvelles fonctionnalités etc... positif!!!
    Envoyé par BlindeKinder le Tue 24 Feb 2009 14:28 Suisse
    alors pour info:
    Je suis arrivé à une configuration relativement stable. Ce qui a fait la différence est que j'ai désactivé l'ACPI (acpi=off sur la ligne de boot dans le menu.lst de grub)... Je donne mes configs qui on joué un rôle:
    -Edirol FA-101
    -acpi=off: plus de crash sans raison de jack et possibilité de descendre plus bas en latence
    -setpci xxxx latency_timer=8f (dans le script de démarrage rc.local): priorité du firewire au max
    -jack 1.9.1/ffado RC1 compilés: du coup ça ne fonctionne plus avec qjackctl, mais je m'en remet.
    -désactivation de l'ahci dans le bios: ça me faisait des blocage au boot et ça le ralentit pas mal
    [edit -noapic nolapic au démarrage: sinon impossible à faire tourner avec acpi=off: IRQ17 (usb libre) est à 60% de CPU (???) et jack ne trouve pas les modules, bien qu'ils soient chargés...]
    Évidement c'est perso à mon ordi... il est très récent et je pense que c'est pour ça que j'ai eu tant de bugs...
    Là je descend à 64/3 à 44100 sans xrun et sans décrochage, du moins avec ardour; soit une latence réelle de 9ms environ (mesuré avec jdelay)
    Ben du coup, je m'essaye à fedora 10/CCRMA, pour changer un peu 😀
    Merci pour votre aide