Pilotes « Open Source » chez Digigram

Posté par  (site web personnel) . Modéré par Benoît Sibaud.
Étiquettes : aucune
0
12
avr.
2003
Matériel
Enfin des cartes audionumériques supportées sous Linux !
Digigram avait donné les spécifications de ses pilotes pour MacOS X en novembre 2002 sir le site ALSA. Depuis l'équipe d'ALSA a réalisé un pilote qui se base sur la toute dernière génération des pilotes ALSA, la 0.9.1 (NdM : il y a une 0.9.2 depuis peu).

Ce pilote OpenSource fait suite à la pétition 'OpenSource driver', et Digigram en est un bel exemple.

Amis constructeurs de composants suivez la lumière... Reprise d'une description de la dépêche précédente :
« ALSA est un ensemble de pilotes, bibliothèques, outils pour remplacer et améliorer OSS. Tout est sous licence GPL/LGPL. Pour une transition en douceur, ALSA fournit également une interface OSS.
La partie noyau a été officiellement intégrée dans la version 2.5 de Linux et sera utilisée par défaut dans la version 2.6. On peut penser que le projet est récent. Mais c'est très loin d'être le cas puisque nous somme nombreux à l'utiliser depuis de nombreuses années entre autres pour ces capacités de full-duplex. Quelques distributions le proposent déjà (Mandrake, SuSE, liste non exhaustive).

Utilisateurs de toutes distributions, n'hésitez pas à indiquer comment se procurer les paquets "qui vont bien". »

Aller plus loin

  • # une méthode pour debian

    Posté par  . Évalué à 10.

    http://www.linuxorbit.com/modules.php?op=modload&name=Sections&(...)

    Ils n'expliquent par contre pas comment faire avec le noyau des paquets debian qui contient déjà les modules pour OSS et qui sont déjà chargés par le système au démarrage (sûrement un coup de discover).

    J'ai pas tenté en virant les fichiers .o des modules oss mais ça devrait avoir le résultat escompté.

    Le gars de Digigram a l'air tout enthousiaste mais j'ai pas compris si c'est vraiment la pétition qui les ont décidé...
    • [^] # Re: une méthode pour debian

      Posté par  . Évalué à 10.

      C'est deux lignes de ce type dans /etc/modules.conf qui indique le driver à utiliser :
      alias char-major-116 snd # utilisation alsa
      alias snd-card-0 snd-ens1371 # driver pour la première carte

      Sinon sur mon système j'ai OSS (livré de base) et Alsa en même temps dans /lib/modules/2.4.xx . C'est quelques lignes dans /etc/modules.conf qui va permettre l'utilisation de l'émulation OSS d'alsa :
      alias sound-service-0-0 snd-mixer-oss
      alias sound-service-0-1 snd-seq-oss
      alias sound-service-0-3 snd-pcm-oss
      alias sound-service-0-8 snd-seq-oss
      alias sound-service-0-12 snd-pcm-oss
      • [^] # Re: une méthode pour debian

        Posté par  . Évalué à 10.

        Ok j'ai recoupé toutes les infos et ça marche.

        En gros j'ai fait:

        apt-get install alsa-modules-2.4.20-1-686
        (puisqu'à côté j'utilise kernel-image-2.4.20-1-686)
        Le jeu des dépendances fera qu'il prendra alsa-base et alsa-utils avec.

        Ensuite rmmod i810_audio pour laisser le champ libre à la détection de la carte.

        Prochaine étape modconf ou je demande le chargement dans la catégorie alsa de snd-intel8x0 et les modules dépendants se chargeront avec.

        Au final mon /etc/modules contient:

        snd-intel8x0
        snd-mixer-oss
        snd-pcm-oss
        snd-seq-oss
        snd-seq-midi

        et les scripts de démarrage les chargeront avant la détection de matériel et donc cette fois c'est le module oss qui est niqué :)
    • [^] # Re: une méthode pour debian

      Posté par  . Évalué à 10.

      c'est vrai ça ! pourquoi faire simple quand on peut faire compliquer !?
      blague a part, debian est une distrib evoluée. ce n'est pas LFS...

      sous une debian propre, la gestion des modules se fait avec modconf et seulement modconf (bon d'accord dans seulement 99,99% des cas).
      pour installer des modules supplémentaires a ceux de la distrib, apt.
      pour alsa : apt-get install alsa-modules-ta_saveur_de_noyo

      tout est expliqué en detail (trop de details ?) dans la page que tu donnes en lien.

      tu trouveras beaucoup de réponses à ce genre de questions en consultant les archives de la list debian-user-french et surtout sa FAQ : http://savannah.nongnu.org/download/debfr-faq/(...)
      C'est LA source d'information a consulter en priorité pour les debianistes ;)
      • [^] # Re: une méthode pour debian

        Posté par  (site web personnel) . Évalué à 3.

        desole mais si tu utilise devfs sur une debian propre, il vaut
        mieux l'eviter le modconf, sinon tu eprt une bonne partie de l'interet
        de devfs (ie le chargement des modules a la demande).
        • [^] # Re: une méthode pour debian

          Posté par  . Évalué à 4.

          et bien, merci, je viens d'apprendre quelque chose. :)
          J'ignorai que devfsd pouvais rendre ce genre de service (pour moi, devfs ne servait "qu'à" organiser l'arborescence sous /dev d'une façon plus "explicite").
          Pour ceux qui sont interressés, la doc de devfs/devfsd : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html(...)
          mea culpa : propre était un abus de language. j'aurais du dire de base ou brut de distrib ou encore sans tripatouillages gruïk ;)

          Si CONFIG_DEVFS_FS=y (support devfs) dans la config du noyau debian, par contre CONFIG_DEVFS_MOUNT (prise en compte de devfs dès le boot sans modification de lilo.conf) n'est pas positionné par défaut et le package "devfsd" a une priorité "optional" seulement (logique puique les deux sont liés). On ne peut pas dire que debian fasse le forcing pour imposer ce mode de fonctionnement. A terme, utiliser devfs par defaut dès l'installation offrira des avantages certains mais ce n'est pas encore le cas (loin s'en faut).

          Enfin, je ne sais pas si l'un est mieux que l'autre pour cette tache mais kerneld est déjà censé charger les modules à la demande, non ? je ne veux pas lancer un debat à la con mais tu sembles dire que la methode "devfs" est plus "propre". En l'état actuel de la distrib (stable) et du point de vue de l'utilisateur lambda, quels sont les arguments pour une solution ou une autre ?

          Ca m'interresse vraiment parce que la gestion des modules du noyau (et plus generalement la gestion des periphériques) est une question récurrente de la part des nouveaux venus et que je trouvais la "solution" modconf sous debian des plus satisfaisante (ie ultra simple si on connait son materiel et efficace) jusqu'à aujourd'hui tandis que devfs était (comme initrd d'ailleurs) une "feature" interressante mais absolument pas indispensable dans l'immediat.
          • [^] # Re: une méthode pour debian

            Posté par  . Évalué à 5.

            C'est un répétition mais il n'est pas nécessaire d'avoir devfs pour avoir le chargement des modules à la demande.
            kerneld n'existe pas sous 2.4 (c'était pour 2.0 et 2.2). Mais le 2.4 support le chargement à la demande sans kerneld. Par contre les modules ne sont pas déchargé automatiquement. C'est pas grave, il suffit de faire un cron avec "rmmod -a" .

            Je ne connais pas modconf, mais il n'est pas sûr qu'il charge les modules. Fait cat "cat /proc/modules" et regarde.
            Par exemple :
            snd-ens1371 15244 2 (autoclean)

            Signale un module chargé "à la demande". 2 indique qu'il est utilisé.

            dummy0 1884 1

            Le module a été chargé avec insmod, manuellement. Même s'il n'est plus utilisé, un "rmmod -a" sera sans effet.

            ide-cd 35164 0 (autoclean)

            ide-cd est chargé à le demande mais n'est plus utilisé. un (ou deux) rmmod -a doit le virer.
            Un petit test :
            # rmmod -a
            Uniform CD-ROM driver unloaded

            Testé sur une machine sans devfs.
        • [^] # Re: une méthode pour debian

          Posté par  . Évalué à 4.

          > le chargement des modules a la demande

          Le chargement des modules ça existe depuis la nuit des temps (depuis Linux 2.0). Et pas besoin de devfs pour ça.
        • [^] # Re: une méthode pour debian

          Posté par  . Évalué à 0.

          J'utilise DevFS sur une debian propre et ce couillon me charge les pilotes OSS avant les pilotes Alsa. C'est bien mon problème...

          Alors je les fais charger dès que possible et ça, ça marche [tm]. Ensuite DevFS fait son travail de création des devices et c'est tout ce que je lui demande.
    • [^] # Re: une méthode pour debian

      Posté par  (site web personnel) . Évalué à 10.

      > Le gars de Digigram a l'air tout enthousiaste mais j'ai pas compris si c'est vraiment la pétition qui les ont décidé...

      L'enthousiasme est compréhensible dans le sens où la communauté des musiciens est souvent montrée du doigt comme chef de file de la copie illicite de logiciels. Il n'est donc pas insensé d'imaginer que le libre pourrait être amené à prendre une certaine place dans un domaine où le commerce de services est mieux accepté et compris que le commerce de produits (par ex. un ordi d'occasion tout bien configuré par quelqu'un en qui on a confiance se vend au dessus de sa cote)

      Personnellement, en tant que collaborateur d'un magazine audio, j'ai depuis un moment soumis à intervalles réguliers la proposition d'une série d'articles éducatifs 'construisez votre enregistreur DtD vous-mêmes', sur une base GNU/Linux + Ardour. Mais la rédaction ne peut pas m'avancer les sous pour acheter l'ordinateur + les cartes (j'envisage RME pour avoir un système susceptible de rivaliser avec Pro Tools - no troll please) et je n'en ai pas la possibilité non plus (si un sponsor potentiel lit ces lignes, n'hésitez pas à me contacter, il faut quand même une machine costaude...).

      Bref, l'avenir est prometteur et je crois aussi que dans une certaine mesure il faut remercier Apple, leader historique dans l'informatique des arts appliqués.
      • [^] # Re: une méthode pour debian

        Posté par  . Évalué à 4.

        Par curiosité, ça coûte combien ce dont tu as besoin ? Et ça fait/sert à quoi au final ?
        • [^] # Re: une méthode pour debian

          Posté par  (site web personnel, Mastodon) . Évalué à 5.

          À enregistrer numériquement en multi-pistes puis ensuite retravailler les prises.
          Le logiciel ProTools est une merveille pour travailler le son de cette manière, puis le retriturer de multiples manières. Hélas, comme tout logiciel professionnel, il est
          1 - très difficile à apprendre
          2 - très exigeant en puissance (d'où l'usages de cartes spécialisées comme les Digi 882)
          3 - très susceptible (l'ajoût de certaines polices sur un système Mac Classic arrive à le planter! il faut qu'il soit seul sur un système dédié)
          4 - très très cher

          Heureusement, il existe une version Light Edition, gratuite sur leur site, mais limité à 8 pistes. À voir, car c'est la référence professionnelle.

          Audacity est une alternative légère pour des petits travaux, mais j'ai rien vu d'aussi complet.
          • [^] # Re: une méthode pour debian

            Posté par  . Évalué à 0.

            <i>> 3 - très susceptible (l'ajoût de certaines polices sur un système Mac Classic arrive à le planter! il faut qu'il soit seul sur un système dédié)
            Mouais ... C'est un logiciel de merde qui est seul sur son marché et qui abuse de ces utilisateurs. Du bon logiciel propriétaire, quoi (Certes, Mac Classic n'aide pas, mais bon ..).
          • [^] # Re: une méthode pour debian

            Posté par  . Évalué à 1.

            sweep a l'air pas si mal :
            http://www.metadecks.org/software/sweep(...)

            enfin surtout quand il s'aura gérer les fichiers temporaires au lieu de charger tout le fichier en mémoire.
            • [^] # Re: une méthode pour debian

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              Il me semble que sweep ne gère qu'un fichier audio à la fois.
              Audacity peut en faire plusieurs à la fois.
              ProTools a en plus laparticuliarité de ne pas modifier le sample lui même mais une image. Avantage: on a toujours le fichier source de dispo.
        • [^] # Re: une méthode pour debian

          Posté par  (site web personnel) . Évalué à 5.

          J'aurais besoin d'un ordi un peu sympa PIII ou IV rapide avec pas mal de ram >= 512Mo + carte audio RME Hamerfall, donc environ 1500 € (je suis tout de même prêt à mettre la main à la poche vu qu'on me paie - peu il est vrai - pour ces articles)

          Le but est de sensibiliser les musiciens/techniciens du son aux problèmes liés à (en résumé) l'EUCD et ses impacts possibles. C'est pourquoi j'ai ce projet d'une série d'articles sous forme de tutoriel pas à pas pour montrer comment, à partir d'un ordi tout nu, on peut installer l'OS (je pense à Debian) avec Alsa et Ardour. Soit peut-être une dizaine d'articles au total, dans l'idée d'une année de publication entre Septembre et Juin.

          Par ailleurs, les cartes et interfaces audio RME ont acquis une bonne réputation et un système informatique d'enregistrement/montage sous GNU/Linux pourrait bénéficier de cette réputation. Le but des personnes engagées dans le projet Ardour est d'ailleurs de commercialiser des services autour de systèmes vendus clefs en main.

          Au final, il s'agit d'avoir un magnétophone multipiste numérique fiable et puissant qui, du fait d'être construit autour du libre, pourrait se montrer tentant non seulement pour les musiciens n'ayant pas les moyens (ou l'envie) de s'offrir Pro-Tools (selon les configurations, compter de 500 à 50 000 €) mais aussi, et sans doute surtout, aux organismes de formation et autres écoles en tout genre. Si ce système en venait à être mieux connu, cela pourrait aussi permettre l'envol du développement de plug-ins libres (qui risque de démarrer grâce à Mac OS X, il y a déjà pas mal d'exemples notamment au format VST) ce qui marquerait vraiment l'avènement de nouveaux moyens de production pour les artistes toujours moins nombreux à entrer dans les boi-boîtes préfabriquées et verrouillées par les majors.

          Bref, le but est aussi de se battre pour la libre expression et la libre circulation des idées, ce qui nécessite des moyens techniques.

          Bon, je m'emporte là... hola bijou, on avait dit pas de troll ;-)
          • [^] # Re: une méthode pour debian

            Posté par  . Évalué à 2.

            Ah oui, quand même ... C'est pas donné ce type de matos. Ça marche bien sous Linux, au moins ? Le site Alsa-project a l'air dans les choux. T'as essayé de demander directement à RME si ils pouvaient t'envoyer une carte pour tester ? Ça coûite rien d'essayer.
            • [^] # Re: une méthode pour debian

              Posté par  . Évalué à 3.

              D'après ce que j'ai lu sur alsa-dev et alsa-user les cartes RME fonctionne très bien sous linux avec ALSA.
              D'aileurs Paul Davis (Mr. Ardour et Mr. jackit) a écrit les drivers pour les RME 9652 et RME HDSP.
              Par contre RME vient de renouveller sa gamme et les drivers ALSA des nouvelles cartes ne sont disponibles que dans la version CVS.
              Voili.
          • [^] # Re: une méthode pour debian

            Posté par  . Évalué à 2.

            Pourquoi ne pas partir d'une distribution type DeMuDi plutôt?
            Ou à la limite d'une RedHat que l'on customise avec les packages disponibles de PlanetCCRMA ?
      • [^] # Re: une méthode pour debian

        Posté par  . Évalué à 1.

        Si tu parviens à tes fins, tu nous préviens ?
      • [^] # Re: une méthode pour debian

        Posté par  (site web personnel) . Évalué à 6.

        <pub éhontée>

        A l'occasion, ça te dirais de jeter un coup d'oeil à notre truc ?

        http://www.all-day-breakfast.com/rosegarden/(...)

        (éditeur/séquenceur MIDI sous Linux - pas fini, mais commence à valoir le coup d'oeil)

        </pub éhontée>
      • [^] # Re: une méthode pour debian

        Posté par  . Évalué à 2.

        >leader historique dans l'informatique des arts appliqués

        Non. non,non,non.
        Les ats graphiques, ok (quoiqu'en chipotant ça serait peut-être plustôt PostScript et adobe en général).

        Pour l'audio, c'est Atari puis Amiga. Les utilisateurs se sont rabattus sans enthousiasme sur Apple (le moins pire de ceux qui restaient).
        • [^] # Re: une méthode pour debian

          Posté par  (site web personnel) . Évalué à 3.

          > Pour l'audio, c'est Atari puis Amiga. Les utilisateurs se sont rabattus sans enthousiasme sur Apple (le moins pire de ceux qui restaient).

          Juste pour le plaisir de chipoter, je suis d'accord pour le Midi et moins d'accord pour l'audio.

          Personnellement, si j'ai acheté un Atari en 1987 c'est parce que je n'avais pas les 35 000 F qu'il fallait débourser pour un Mac 128.

          Le premier séquenceur logiciel que j'ai utilisé tournait sous Apple II (je travaillais alors dans un magasin de musique à Lyon, et le Xerox store situé en face - rue Mercière pour les connaisseurs - nous avais prêté l'Apple II en question). Le soft était fait par Dr T. et Google ne m'aide pas à retrouver son nom.

          Cela dit, les séquenceurs "hard" étaient aussi beaucoup utilisés, je me rappelle du Korg SQD-1, Yamaha QX-1 et QX-5, juste avant que ne règne le MC-500 Roland.

          Mais pour l'audio, je persiste et signe avec Sound Designer II que j'ai utilisé pour la première fois avec un Mac IIfx en 88.
  • # Re: Pilotes « Open Source » chez Digigram

    Posté par  . Évalué à 3.

    C'est pas joli de copier :
    http://linuxfr.org/2003/03/13/11698.html(...)

    Tu y aller, tu as ma bénédiction. Sinon, il y a une "licence" pour les news. Ce serait bien d'avoir une licence libre.

    > Utilisateurs de toutes distributions, n'hésitez pas à indiquer comment se procurer les paquets « qui vont bien ».

    Est-il nécessaire de rappeler où trouver alsa pour RedHat ?
    Non, mais on sait jamais :
    http://freshrpms.net/docs/alsa/(...)

    Les tarballs d'origines fournissent aussi les .spec « qui vont bien » .
    • [^] # Re: Pilotes « Open Source » chez Digigram

      Posté par  . Évalué à 8.

      c'est un peu le mélange des genres, je suis bien d'accord, mais la news concerne surtout l'arrivée d'un nouveau constructeur dans le "camp" de ceux qui fournissent les specs et meme des drivers pour leur matériel (si j'ai j'interprete bien la pensee de l'auteur :)).
      ceci dit, est-ce si exceptionnel que l'on doive le signaler pour chacun d'entre eux dans une news ?
      peut-etre... aux moderos d'en decider apres tout.
      • [^] # Re: Pilotes « Open Source » chez Digigram

        Posté par  . Évalué à 1.

        J'ai rien contre la news, elle est très bien. Je dis seulement que la partie "ALSA est un ensemble de pilotes, ... ... se procurer les paquets « qui vont bien »." a été pompée d'une autre news.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.