Sortie d'ALSA 1.0.0pre1

Posté par  . Modéré par Nÿco.
Étiquettes :
0
20
nov.
2003
Noyau
ALSA, l'outil de gestion des pilotes audio destiné à remplacer OSS sur le noyau Linux 2.6, a sorti sa première release candidate hier. Si les tests sont concluants, la version finale devrait sortir ce mois-ci.

Comme l'indiquent les développeurs, il est important qu'un maximum de gens testent cette mouture et fassent des rapports de bogues, afin bien sûr d'obtenir une version finale la plus stable possible. On devine l'ampleur de la tâche quand on connait le nombre de matériels différents supporté par ALSA.
Il est à noter que les développeurs précisent qu'ils apprécieraient des retours même si aucun problème n'a été rencontré. Takashi Iwai a annoncé sur les mailing list d'ALSA hier :

"Hi all,

as you might have already seen on the web news page, we released
1.0.0pre1 tarball. This is intended for the wide tests before the
official 1.0.0 release. We planned to release 1.0.0 (hopefully) in
this month, so please everyone test this version and give bug reports
now.

Especially, if you have a card or a mobo with ICH (or compatible)
chip and *multiple* AC97 codecs, testing this version is appreciated.
Please give (also positive) feedback whether it works. The handling
of multiple codecs was changed recently, but not tested well because
of lack of hardware."

Apparemment, le message de l'annonce n'est pas passé sur les archives des mailing-list, je n'ai donc pas pu fournir le lien vers celle-ci.

A présent, faites chauffer les compilateurs :-)

Aller plus loin

  • # Re: Sortie d'ALSA 1.0.0pre1

    Posté par  . Évalué à 2.

    La version finale du noyau 2.6.0 contiendra la version finale 1.0 d'ALSA ?

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

      Posté par  . Évalué à 9.

      La première version stable de linux 2.6 contiendra logiquement la dernière version déclarée stable d'ALSA, donc la 1.0.0 si aucune autre ne sort d'ici là. Pourquoi intégrer une version de développement si une version stable est sortie, franchement ?

      • [^] # Re: Sortie d'ALSA 1.0.0pre1

        Posté par  . Évalué à 1.

        Parce que son fonctinnement est plus éprouvé?

        "The handling of multiple codecs was changed recently, but not tested well because of lack of hardware"

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

      Posté par  . Évalué à 3.

      A ce propos:
      - Est-ce que la version fournie avec le noyau inclu également les utilitaires et bibliothèques, ou ne concerne-t-elle que les drivers ?
      - Y-a-t-il un avantage particulier à utiliser la mouture incluse dans le noyau ? Parce-que personnellement, quite à la compiler moi-même, je préfère toujours avoir la dernière version...

      • [^] # Re: Sortie d'ALSA 1.0.0pre1

        Posté par  . Évalué à 4.

        Je crois qu'il y a besoin des utilitaires alsa extérieurs : seuls les pilotes de périphériques sont inclus.

        A mon avis, l'avantage d'utiliser la mouture incluse est qu'on peut la compiler en dur dans la noyau (alors que tu n'as que des modules sinon)... je ne vois rien d'autre... mais je ne suis pas un expert, je n'en suis pas sûr.

        • [^] # Re: Sortie d'ALSA 1.0.0pre1

          Posté par  . Évalué à 2.

          J'ai une idée assez floue de alsa dans le noyau, dans debian c'est fourni avec des scritps d'initialisation (sysv) je suppose qu'ils ne seront pas présent dans la version noyau, cela fonctionnera-t-il comme des modules normaux ou une solution hybride sera mise en place ? Je suppose que oui car Slackware par exemple n'utilise pas sysv, mais a besoin de fichiers de config, où seront-ils placés ? Sera-t-il à la distrib de faire le travail où une soution standard LSB sera mise en place ?

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

            Posté par  . Évalué à 5.

            La partie d'Alsa incluse dans le noyau, ce sont les pilotes de périphérique. Ces pilotes peuvent être compilés en dur dans le noyau ou sous forme de modules.

            Dans le dernier cas, il y a besoin d'un fichier de configuration indiquant quels modules charger : /etc/modules.conf pour Debian, Mandrake, etc (je ne connais pas trop), et /etc/rc.d/rc.modules pour la Slackware (excellente distrib' ;-) ).

            Je ne crois pas qu'il y ait besoin de fichiers supplémentaires pour une utilisation standard d'Alsa - un module par puce, on charge le bon module et voilà.

            Quelqu'un a-t-il une autre opinion ou des lumières à apporter sur le sujet ?

            • [^] # config modules debian

              Posté par  . Évalué à 1.

              je précise que pour de debian les fichiers de config des modules sont:
              /etc/modules qui indique quels modules sont chargés lors du boot

              ensuite chaque module (ou groupe de modules) peut avoir un fichier dans le répertoire /etc/modutils

              quand on lance commande update-modules, le fichier modules.conf est généré automatiquement (ne pas l'éditer) à partir des fichiers de /etc/modutils

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

            Posté par  . Évalué à 4.

            Alors voilà ma conclusion, après vérification : pour une utilisation standard, le chargement des modules suffit ; pour une utilisation avancée, il existe des fichiers supplémentaires, l'un situé dans le répertoire home de l'utilisateur, .asoundrc, et l'autre dans /etc, alsa.conf. Ce sont des emplacements tout à fait standards, il n'y a pas de problèmes.

            Plus d'infos ici :
            http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3(...)

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

            Posté par  . Évalué à 2.

            > Slackware par exemple n'utilise pas sysv

            En effet, Slackware utilise le système de démarrage du style BSD. Cependant, elle supporte très bien les scripts de démarrage SysV : c'est le script /etc/rc.d/rc.sysvinit qui est chargé de cela et qui est appelé automatiquement par les scripts de démarrage standards. Pour plus de détails, lire les commentaires qui figurent au début de ce fichier.

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

            1. Le noyau 2.6.0 propose le driver alsa, rien de plus.
            Pour une utilisation complete, il faut aussi:

            a) alsa-lib (librairie pour les programmes)
            b) alsa-tools (entre autres, alsamixer, alsactl)
            c) alsa-oss (emulation oss)

            2. Scripts de demarrage: tu as besoin d'un script pour charger tes modules si tu as compile alsa en modules.
            Mais tu as aussi besoin, dans tous les cas, d'un script de demarrage pour, notamment, restaurer le volume du mixer (alsactl restore).
            Donc le script et d'autres packages sont necessaires a une bonne utilisation d'alsa avec le 2.6.0.

            3. Concernant la Slackware, elle a des scripts BSD mais accepte aussi les scripts System V.
            Dans la derniere Slack 9.1, qui est prete pour le 2.6.0, il y a un script rc.alsa qui charge les modules et restaure les volumes au demarrage.

            • [^] # Re: Sortie d'ALSA 1.0.0pre1

              Posté par  . Évalué à 1.

              > b) alsa-tools (entre autres, alsamixer, alsactl)

              alsamixer et alsactl sont fournit par alsa-utils, alsa-tools met à disposition d'autres utilitaires un peu moins essentiels.

              > 2. Scripts de demarrage: tu as besoin d'un script pour charger tes modules si tu as compile alsa en modules.
              Mais tu as aussi besoin, dans tous les cas, d'un script de demarrage pour, notamment, restaurer le volume du mixer (alsactl restore).

              Un tel script ("alsasound") existe déjà dans le répertoire "utils" des sources de alsa-drivers . Il est automatiquement copié dans le répertoire "init.d" de votre distrib lors de l'installation des drivers mais, sauf erreur, n'est pas utilisé par défaut (il suffit de créer les liens Sxx/Kxxalsasound correspondants). Chez moi, ça marche plutôt bien...

              • [^] # Re: Sortie d'ALSA 1.0.0pre1

                Posté par  . Évalué à 2.

                Sous Debian, il existe déjà un fichier /etc/init.d/aumix qui dispense d'utiliser le script alsasound. Par défaut, il ne s'occupe que des volumes d'OSS. Afin de pouvoir prendre également en charge les volumes et paramètres du mixer ALSA, il suffit de changer la ligne
                HANDLEALSA="no"
                en
                HANDLEALSA="yes"

        • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

          > alors que tu n'as que des modules sinon

          J'ai vu plusieurs posts qui conseillaient de les laisser sous forme de modules.
          D'ailleurs pour l'avoir testé moi même, la version compilé en dur dans le noyau
          pour les emu10k1 (Sb live! player and co) ne marche absolument pas dans les noyaux 2.6 actuels !

          • [^] # ALSA & modules

            Posté par  . Évalué à 1.

            les laisser sous forme de modules
            Un autre avantage est de pouvoir les mettre à jour sans avoir à recompiler tout un noyau... et donc à devoir rebooter pour en bénéficier...

            Sur un noyau 2.4.2+ powerpc, la solution "modules" a aussi été pour moi la seule façon d'avoir un son convenable (définition de l'ordre de chargement).

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

            Jamais eu de probleme avec alsa et emu10k1 en dur dans le noyau sur les 2.6.0-test.
            Je suis constamment en 2.60-test depuis la version 4 (je teste meme les patches BK de temps a autres) avec une SB live ! qui marche du tonnerre.

            Je soupconne fortement un probleme de config. Tu peux detailler ton probleme, ta distrib, etc ?

      • [^] # Re: Sortie d'ALSA 1.0.0pre1

        Posté par  . Évalué à 2.

        Le kernel (sauf erreur) ne contient que les drivers pas les librairies et les outils.
        L'avantage est de pouvoir mettre alsa en dur et pas en modules (c'est ce que j'ai fait).
        Mais sinon pas d'autre gros avantages.

        • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

          Ben c'est déjà un bon avantage de pouvoir mettre une telle gestion en statique dans le noyau, c'est quand même important le son, non ?
          Et le fait de l'intégrer directement dans le noyau permet d'accélérer quelques peux le bastring (c pas énorme mais ca l'ai quand même) et faire quelques petites économies, surtout à l'heure où beaucoup d'applis intègrent le son (enfin de plus en plus).

          Un jour libre ?

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

            Oui mais tu perd l'avantage du module: la possibilite de decharger le systeme (pour mettre a jour/plantage/..) et de la recharger sans
            redémarrer l'ordinateur.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à 0.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Sortie d'ALSA 1.0.0pre1

                Posté par  . Évalué à 1.

                en meme temps, je suis pas sur que l'utilisateur de base, qui utilise sa box pour une utilisation normale et qui n'est pas trop parano, desactive le support des modules pour de telles raisons... a la rigueur sur un serveur exposé, mais la l'interet d'alsa est plutot limité en gal.. enfin je dit ca je dit rien..

              • [^] # Re: Sortie d'ALSA 1.0.0pre1

                Posté par  . Évalué à 1.

                > mais tu peux gagner en securite si tu ne compiles pas le support des modules...

                Ah ? Je serais intéressé par plus de détail au sujet de cette information sur le gain en sécurité gagné en ne compilant pas les modules ! Merci.

                • [^] # Re: Sortie d'ALSA 1.0.0pre1

                  Posté par  . Évalué à 1.

                  j imagine qu il parle de la faille ptrace qui exploitait un bug dans le chargement des modules , d autre part si tu desactives le chargement des modules , tu evites une partie des rootkits.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 1.

                    Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Sortie d'ALSA 1.0.0pre1

                  Posté par  . Évalué à 1.

                  Cela évite de "monter" (insmod) un module qui serait défaillant et produirait des erreurs pouvant ammener le système à planter par exemple.
                  Sur un serveur, par exemple, il est assez rare d'ajouter du nouveau matériel et encore plus s'il s'agit d'une carte son (quoique).

                  • [^] # Re: Sortie d'ALSA 1.0.0pre1

                    Posté par  . Évalué à 1.

                    mais bon je vois mal alsa sur un serveur !!

                  • [^] # Re: Sortie d'ALSA 1.0.0pre1

                    Posté par  . Évalué à 1.

                    Cela évite de "monter" (insmod) un module qui serait défaillant et produirait des erreurs pouvant ammener le système à planter par exemple.

                    Ca ôte surtout la possibilité à un intrus potentiel de charger un petit module maison qui ferait la pluie et le beau temps dans le système (en un mot: un rootkit).

                    D'autant qu'il est possible de charger un module de manière qu'il soit invisible au lsmod et au /proc/modules (j'ai plus la source, mais ça avait été testé il y a pas mal de temps déjà). Donc, sur un serveur, laisser le support des modules c'est loin d'être très malin.

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

            Bah dans une utilisation normale, tu n'as qu'un chargement et déchargement du module. Une fois chargé, je vous ferais remarqué qu'un module est le noyau tout simplement. Cela permet juste une plus grande flexibilité.

            ++chris;

          • [^] # Re: Sortie d'ALSA 1.0.0pre1

            Posté par  . Évalué à 1.

            la seule chose que tu gagnes c'est le temp CPU pour charger tes modules pas plus !

            càd : tu gagnes rien

        • [^] # Re: Sortie d'ALSA 1.0.0pre1

          Posté par  . Évalué à 1.

          L'avantage, c'est surtout que ça compile.
          Je ne sais pas si les archives ALSA sont compatibles 2.6, mais je n'ai encore jamais réussi à en compiler une seule sur noyau 2.6.

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

      A priori, non (contrairement à tout ce qui a été dit ici). Linus ne veut plus que des bugfix pour le 2.6.0. Bref, un patch pour upgrader ALSA en 1.0.0, ça ne passera pas.

      De plus, contrairement à ce qui a aussi été dit plus bas, la vitesse en module ou en dur est strictement identique. Il n'y a absolument aucune raison pour que l'un ou l'autre soit plus rapide.

      • [^] # Re: Sortie d'ALSA 1.0.0pre1

        Posté par  . Évalué à 3.

        Si on aime déformer les mouches, y'a bien un temps de latence (appel de fonction non implémentée dans le kernel, recherche de la fonction dans les modules, chargement du module, puis appel de la fonction)
        Mais bon, ça arrive qu'une fois... l'incidence est négligeable.

  • # Re: Sortie d'ALSA 1.0.0pre1

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

    Sortie de la rc1 le 19, une prévision (espérance) de la finale ce mois ci

    Ca laisse à peine une douzaine de jours. C'est pas un peu court pour un cycle de rc ?

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

      Ben ca dépend de la stabilité du pre1. Si il est relativement dépourvu de bug, ca passera comme une lettre à la poste. Mais vu la taille du chmilblic, ca risque effectivement de prendre un peu (beaucoup) plus de temps.

      Un jour libre ?

  • # Re: Sortie d'ALSA 1.0.0pre1

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

    et quand est-ce qu'on pourra se passer d'ESD et avoir plusieurs sons en même temps ?

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

      Posté par  . Évalué à 4.

      A ma connaissance, alsa n'a pas pour vocation de servir de serveur de son.
      Si ta carte supporte plusieurs canaux en hardware, alsa peut permettre d'en profiter, mais c'est tout.

      Personnellement, j'ai découvert en installant alsa que c'était le cas pour ma carte son intégrée de mon portable :-)

      Si tu cherche le temps réel, il faut tuner au mieux ton serveur de son (voire passer à jackd mais peu d'applis "non pro" savent l'utiliser) et ton noyau (ou utiliser un noyau 2.6 ou le kernel-multimedia pour mandrake par exemple)

      • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

        J'ai remarqué qu'alsa mixait parfaitement plusieurs sons à la fois, mais sur mon i845 monté sur un PIV à 2MHz, il laisse une latence d'arrêt énorme ! (parfoi plus d'une seconde). pour un utilisateur lambda ça passe, mais pour quelqu'un qui fait du son, c'est insupportable. Rester en OSS est parfois moins lourd...

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

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

      Oui, en userland uniquement.
      http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3#softmix(...)

  • # Re: Sortie d'ALSA 1.0.0pre1

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

    Faute de frappe + orthographe :
    release canditate/release candidate
    qu'il apprécieraient/qu'ils apprécieraient

    ++

  • # Re: Sortie d'ALSA 1.0.0pre1

    Posté par  . Évalué à 1.

    Comment on fait pour la tester?
    Si j'installe la 1.0.0pre1, est ce qu'il faut recompiler/reinstaller tout les soft qui utilise du son?

    • [^] # Re: Sortie d'ALSA 1.0.0pre1

      Posté par  . Évalué à 1.

      Cela dépend de quelle version tu parts. Si c'est la 0.5, il va falloir que tu fasses pas mal de ménage, mais si c'est une version rel;ativement récente, cela ne devrait pas poser de problème.

Suivre le flux des commentaires

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