Open Sound System de retour vers le libre

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
1
8
juin
2007
Son
Dev Mazumdar de 4Front, l'éditeur des pilotes audio Open Sound System (OSS) annonce officieusement un retour vers une licence libre, après avoir fermé le code des pilotes il y a quelques années.

« Les rumeurs sont vraies, nous prévoyons d'ouvrir le code d'Open Sound (le 14 juin). Nous fournirons le code source sous [la licence] CDDL pour Solaris et GPLv2 pour Linux, BSD, OpenServer, etc. »

Dans les commentaires de la dépêche d'OSNews, il est précisé que le choix de la licence n'est pas encore finalisé et que l'étude est encore en cours (suite à des regrets du choix de la GPLv2 par des utilisateurs de BSD).

En tant qu'utilisateur de Linux, on relèvera tout de suite le double emploi de ces pilotes face à ALSA, intégré au noyau suite à la fermeture du code d'OSS, mais il est important de préciser que les pilotes OSS ont la particularité d'être multi-platesformes. Il y a beaucoup d'incertitudes sur l'accueil de ces pilotes, même si bien entendu, la libération de code est toujours une bonne nouvelle. En effet, l'adoption d'ALSA par les développeurs est bien avancée tout en restant assez longue, mais apporte beaucoup en support multimédia à Linux, particulièrement du point de vue utilisateur.

Or, par leur architecture plus ancienne (l'origine du projet remonte à 1992), OSS ne peut représenter qu'un pas en arrière : un retour vers l'obligation d'utiliser un serveur de mixage ou des problèmes de conflit d'accès aux cartes sons (du moins, pire que la situation actuelle), sans mentionner les possibilités avancées d'ALSA. À une époque où certains vont jusqu'à réclamer un mixage audio à l'intérieur du noyau, on peut s'attendre à des débats sur le retour de ces pilotes. Notamment, il est certain que les développeurs souhaitant avoir une compatibilité entre différents systèmes d'exploitation s'appuieront, directement ou indirectement, sur OSS.

La solution habituelle est d'utiliser une couche d'abstraction, mais elle nécessite l'adoption de tous les développeurs pour répondre réellement au problème et nous avons constaté par le passé l'échec (relatif) des différentes tentatives (même la couche de compatibilité alsa-oss ne permet pas résoudre le problème du mixage). L'espoir est que tous les prochains projets voulant une compatibilité OSS utiliseront une abstraction permettant un support natif d'ALSA à côté d'OSS.

ALSA étant maintenant bien implanté, on peut espérer que les applications de bureautique, multimédia ou ludiques principalement développées pour GNU/Linux garderont (au moins) ALSA pour le son, pour épargner les problèmes du quotidien, laissant les problématiques plus complexes à ceux qui ont des besoins avancés.

On peut aussi noter que l'étendue de la compatibilité matérielle d'ALSA est bien plus large que celle d'OSS, mais parfois au prix de la qualité ou degré de fonctionnalités du pilote. Pour ceux disposant de matériel ancien sans compatibilité ALSA, OSS peut s'avérer être une solution.

Aller plus loin

  • # *hum*

    Posté par  . Évalué à 10.

    Or, par leur architecture plus ancienne (l'origine du projet remonte à 1992), OSS ne peut représenter qu'un pas en arrière : un retour vers l'obligation d'utiliser un serveur de mixage ou des problèmes de conflit d'accès aux cartes sons (du moins, pire que la situation actuelle), sans mentionner les possibilités avancées d'ALSA.

    Faudrait un peu se renseigner avant de rediger ce genre de commentaire dans une news , OSS supporte Alsa de la meme facon qu alsa support OSS ( par emulation ) , de plus OSS 4.0 a aussi un mixeur "a la" dmix , et en plus il supporte le full-duplex , ce que ne fait pas dmix..

    http://www.opensound.com/press/2007/OSSv4.txt

    • [^] # Re: *hum*

      Posté par  . Évalué à 7.

      Mes confuses, j'ai regardé la doc de l'API mais je suis passé trop vite sur les releases notes. L'une des raisons de ma négligence est que je n'ai pas voulu partir trop vite sur l'idée que ce serait exactement la même version qui serait libérée. Enfin je l'aurais lue attentivement, j'aurais mentionné tout ca bien évidement.

      Bon en tous cas, tout ce que j'ai vu a encore l'air de tourner a coups d'ouverture de fichier spécial (/dev/dsp), cela voudrait il dire que le mixer est dans le noyau ?

      Enfin, tout cela sera rétabli dans la prochaine news pour la libération officielle des sources.

      • [^] # Re: *hum*

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

        D'après les explications sur OSNews, il semble que la plupart des critiques envers OSS sont en fait contre la version GPL incluse dans Linux un fork très ancien, qui d'après eux n'a jamais évolué alors que l'original serait autant voir plus performant qu'ALSA, tout en étant portable. Le blog de l'auteur original donne un point de vue bien différent du "flan" Alsa : http://opensound.com/hannublog/ . Il semble assez remonté contre ALSA, allant jusqu'à les accuser de FUDer. Chacun jugera.

        • [^] # Re: *hum*

          Posté par  . Évalué à 4.

          Bon, sans être un expert (loin de là), je fréquente un peu la liste "linux-audio-dev", et je peux confirmer qu'il y a effectivement une petite guerre oss/alsa, avec comme toujours du fud et des exagérations des deux côtés.

          Le "plus performant qu'Alsa", par exemple, demande à être pris avec *beaucoup* de précautions... Pour la portabilité c'est vrai (vu qu'alsa est spécifique à linux ^^), mais aujourd'hui une appli audio qui se respecte n'utilise pas directement les drivers, elle passe par un serveur (jack si c'est pour de la MAO), c'est donc à lui d'être portable.

          Apparement Alsa et OSS utilisent des approches assez différentes, et certains grands noms parmi les dévelopeurs de soft MAO libres semblent préférer celle d'Alsa (voir [http://lalists.stanford.edu/lad/2006/11/0073.html] par exemple), mais ce n'est pas tout blanc ou tout noir.

          Les dévs d'oss sont ceux qui ont rendu l'audio possible sous linux, ça mérite le respect... C'est aussi ceux qui l'ont rendu "closed-source", d'où le léger antagonisme de la communauté...

          • [^] # Re: *hum*

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

            J'ai seulement rapporté le point de vue de l'autre côté...

            Oui c'est bien d'avoir des serveurs portables, mais si on veut porter les drivers pour avoir plus de support hardware ?

            "certains" ? cela veut-il dire que tous les autres sont pour OSS ? :P

    • [^] # Re: *hum*

      Posté par  . Évalué à 3.

      En tout cas, niveau comm, j'ai l'impression qu'OSS a très mal joué au final.
      J'étais persuadé que OSS n'était qu'un vieux truc pour lequel on ne gardait une compatibilité que pour des raisons historiques. À chaque fois qu'un logiciel récent choisissait OSS plutôt qu'ALSA, je n'arrivais pas à comprendre.
      Je ne savais absolument pas que le projet continuait en closed source et proposait des fonctionnalités similaires à ALSA.

      Bref, tant qu'à faire OSS devrait changer de nom pour sa prochaine version libérée, pour ne pas être confondu avec le vieux bousin marqué "deprecated" dans le noyal !

  • # pourquoi ?

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

    Il manque a mon avis une info a cette news : pourquoi ils avaient fermé le code à l'époque ?

    quelqu'un est au courant ?

    • [^] # Re: pourquoi ?

      Posté par  . Évalué à 4.

      Il me semble que le développeur, Hannu Savolainen, a créé sa société 4Front Technologies et livrait des améliorations d'OSS sous une licence propriétaire.

      vw

      • [^] # Re: pourquoi ?

        Posté par  . Évalué à 1.

        Ben j'espère qu'OSS fera gaffe à sa licence maintenant (ils feraient bien d'avoir une licence double).

        Parce que remettre OSS en GPL pour le répandre et le fermer après pour faire de l'argent...

        Bah je fais confiance à Linus qui nous sortira bien un petit mail sympatique à l'endroit d'OSS...

  • # portaudio

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

    La solution habituelle est d'utiliser une couche d'abstraction

    Comme par exemple l'excellentissime portaudio http://www.portaudio.com/ que je recommande chaudement

    • [^] # Re: portaudio

      Posté par  . Évalué à 5.


      Comme par exemple l'excellentissime portaudio http://www.portaudio.com/ que je recommande chaudement


      Ou, pour un autre usage, JACK (http://jackaudio.org), pour qui tous les programmes devraient supporter la sauvegarde de session et le transport synchronisé (avis aux développeurs contributeurs).

      Maintenant, sans vouloir dénigrer ALSA ni les efforts d'OSS, un système audio centralisé sur un démon me semble plus pratique qu'une couche de pilotes qui sait tout faire. Ils devraient se concentrer sur la stabilité et la latence (qui sont déjà remarquables) plutôt que sur les fonctionnalités.

      Donc OSS de retour, c'est une bonne nouvelle, puisque cela fera un meilleur support pour certaines cartes et de toute façon, on va abstraire tout ça derrière une belle lib bien complexe qui fait le travail !

      • [^] # Re: portaudio

        Posté par  . Évalué à 2.

        de toute façon, on va abstraire tout ça derrière une belle lib bien complexe qui fait le travail !


        C'est déjà le cas en réalité : (bientôt) Gstreamer pour Gnome et Phonon pour le futur KDE

        Ces projets sont obligé de le faire vu qu'ils visent d'autres plateforme que Linux...

        • [^] # Re: portaudio

          Posté par  . Évalué à 7.

          Oui, sauf que Phonon et GStreamer n'ont rien à voir.
          GStreamer est effectivement une "belle lib bien complexe qui fait le travail", comme xine ou arts.
          Par contre Phonon est une simple API qui ne fait aucun travail, mais qui est une couche d'abstraction du backend audio utilisé (xine, xmmm ou ... GStreamer).
          Dans le monde des bases de données, ça revient à comparer postgreSQL et ODBC ... ça n'a pas de sens.

      • [^] # Re: portaudio

        Posté par  . Évalué à 3.

        de toute façon, on va abstraire tout ça derrière une belle lib bien complexe qui fait le travail !
        Non pas une lib, mais un serveur audio.

    • [^] # Re: portaudio

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

      SDL, OpenAL, Allegro, JACK, (etc.) supportent ALSA et OSS. SDL et OpenAL supportent plateformes. OpenAL supporte aussi Mac OS X, BSD, Solaris, DirectSound, Direct3D, Xbox, Xbox 360, BeOS et tout ceux que j'oublie. SDL supporte aussi DirectSound, BeOS, (Mac OS X, Solaris, FreeBSD) et ceux que j'oublie.

  • # La jungle des API audio sous linux

    Posté par  . Évalué à 6.

    Par l'auteur du plugin flash pour linux:
    http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the_ju(...) (en anglais)
    Il a fait un graphe avec (presque) toutes les solutions qui existent pour programmer de l'audio sous linux.

    Je me demande si le retour d'OSS en GPL ne risque pas d'alourdir tout ça.

    • [^] # Re: La jungle des API audio sous linux

      Posté par  . Évalué à 2.

      En même temps, si on n'aime pas le bazar, on peut rester sur les systèmes de type cathédrale (branlante) ...

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # J'suis sur qu'il a pas tout mis ...

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

      echo "beep" > /dev/dsp

      ca a ptet des chances de produire un son, non ?

    • [^] # Re: La jungle des API audio sous linux

      Posté par  . Évalué à 2.

      En fait même sous windows y plein de librairies pour faire de l'audio, c'est pas spécifique à linux...
      Non, le problème est ailleurs, c'est celui du rendu audio de plusieurs sources vers une même carte son qui pose problème, c'est pourquoi certains pensent à mettre un démon pour centraliser tout ça, ou bien d'autres pensent que l'on devrait rajouter un mixer audio dans le Kernel...
      Personne n'aime rajouter de tels morceaux dans le kernel, pourtant on l'a bien fait avec le DRI coté vidéo. En plus mettre un mixer sur le noyaux aura l'avantage de mettre tout le monde d'accord, alors qu'un démon, c'est plus dur.
      Mais n'étant pas un spécialiste du kernel linux je ne saurai dire ce qui pose réellement problème de mettre ça dans le noyau.

      • [^] # Re: La jungle des API audio sous linux

        Posté par  . Évalué à 3.

        pourtant on l'a bien fait avec le DRI coté vidéo.
        Tu veux dire drm, le dri est en userspace. Et puis il y avait une alternative ?
        Pour gérer les interruptions des cartes video, partagé le hardware entre la 2D du serveur X, la 3D, ..., un driver kernel est assez naturel.

        Mais n'étant pas un spécialiste du kernel linux je ne saurai dire ce qui pose réellement problème de mettre ça dans le noyau.
        Aucun mais quel serait l'avantage de le mettre dans le kernel.
        En le mettant en userspace tu as plusieurs avantage :
        - tu peux utiliser des flottants, instruction assembleur speciales (mmx, sse, ...).
        - si ton démon à des bugs (débordement, ...) il ne risquera pas de faire planter toute pas machine.
        - le démon en espace utilisateur peut utiliser facilement la couche réseau pour déporter des cartes sons via le réseau.

        et j'en passe.

        • [^] # Rien à voir: MMX/SSE

          Posté par  . Évalué à 1.

          Tu veux dire que le noyau n'utilise pas les optimisations MMX et SSE ?

          • [^] # Re: Rien à voir: MMX/SSE

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

            Si, mais il lui faut sauvegarder les registres en rapport avec ces instructions avant, et les restaurer après(car il faut que quand la main est rendu à l'userspace, les registres soient dans le même état).
            Donc c'est assez lourd.

            • [^] # Re: Rien à voir: MMX/SSE

              Posté par  . Évalué à 2.

              Et donc c'est utiliser que dans les cas tres precis (crypto, RAID, ).

    • [^] # Re: La jungle des API audio sous linux

      Posté par  . Évalué à 4.

      MAO Linux présente d'autres schémas de l'état actuel de la jungle son développé autour d'Alsa :
      http://www.linuxmao.org/tikiwiki/tiki-index.php?page=pr%C3%A(...)

      • [^] # Re: La jungle des API audio sous linux

        Posté par  (Mastodon) . Évalué à 2.

        oui mais en voulant trop simplifier mon schéma est à la limite du faux.

        /troll : et puis, il insiste pas assez sur le fait que tous et toutes les applis ont à gagner à se fédérer, au moins à prendre en compte, JACK (sans renier ni enlever la diversité) Jack powa /troll

    • [^] # Re: La jungle des API audio sous linux

      Posté par  . Évalué à -3.

      MAO Linux présente d'autres schémas de l'état actuel de la jungle son développé autour d'Alsa :
      http://www.linuxmao.org/tikiwiki/tiki-index.php?page=pr%C3%A(...)

    • [^] # Re: La jungle des API audio sous linux

      Posté par  . Évalué à -4.

      MAO Linux présente d'autres schémas de l'état actuel de la jungle son développé autour d'Alsa :
      http://www.linuxmao.org/tikiwiki/tiki-index.php?page=pr%C3%A(...)

  • # ALSA...

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

    > ALSA étant maintenant bien implanté,

    Euh, sous Linux peut-être, c'est gentil d'oublier tous les autres.
    OSS fonctionne sous d'autres Unices, et il y a fort à parier que d'autres OS Libres à public plus restreint (ReactOS, Haiku, AROS...) pourront bénéficier d'un support audio plus large.
    ALSA étant depuis le début uniquement sous Linux il est vain d'imaginer pouvoir le porter.

    • [^] # Re: ALSA...

      Posté par  . Évalué à 4.

      ALSA étant depuis le début uniquement sous Linux il est vain d'imaginer pouvoir le porter.
      Je crois que certains (bsd) on essayé de le porter ou faire une couche d'emulation et se sont cassé les dents.

      Vu que cette version d'oss supporte l'emulation alsa, c'est une bonne nouvelle pour eux.

    • [^] # Re: ALSA...

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

      Ouais, en tant que BSDiste, je maudis les developpeurs de LL qui pense que le logiciel libre se résume à Linux, et qui codent tout avec des solutions pas portables, comme A LINUX SA...

      OSS youpi \o/

    • [^] # Re: ALSA...

      Posté par  . Évalué à 2.

      AROS a deja un sous-systeme son appele AHI, au mieux les drivers pourraient etre portes, mais OSS en lui-meme, je suis pas sur de l'interet dans le cas d'AROS.

      • [^] # Re: ALSA...

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

        Haiku aussi a un sous-système son, le Media Kit, hérité de BeOS et cloné depuis même sous Linux (GStreamer ? :p)...
        Bien sur c'est pour les drivers. porter OSS sur autre chose qu'Unix ça n'a pas beaucoup d'intérêt sans les drivers puisqu'il y a déjà une API pour le son.
        Mais bon, il y a Hurd aussi, je sais pas s'ils sont en état d'avoir du son ni s'ils ont une API pour ça (troll :p).

  • # Trop tard ?

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

    On peut craindre que cette libération arrive trop tard. ALSA est maintenant le système par défaut de toutes les distributions. Il faudrait que OSS ait un gros avantage sur ALSA pour que l'on revienne à OSS. Je ne pense pas que ce soit le cas.

    D'autres projets ont été libérés trop tard. Je pense par exemple à Ingres, issu des mêmes sources que Postgresql. Je ne crois pas que Ingres puisse revenir à la hauteur de Postgresql malgré ses succès d'il y a 10 ou 15 ans.

    • [^] # Re: Trop tard ?

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

      C'est encore une fois oublier qu'il n'y a pas que Linux.
      ALSA c'est tellement Linux-seulement que c'est dans le noyau et importable ailleurs.
      Sur les autres plateformes OSS a donc le "gros avantage" d'être portable :D
      Par ailleurs certains semblent dire que le multiplexage d'OSS est bien plus simple à utiliser que celui d'ALSA.

      • [^] # Re: Trop tard ?

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

        D'ailleurs, sans présumer des autres, mon portable n'a toujours pas de sons sous Linux avec ALSA...
        ASU[SX] l4500r (chipset ATI IXP pourri, AC97), je me rappelle avoir fait du bruit une fois, depuis plus moyen. Tfaçon deb met 10 minutes à booter dessus. :-(
        (par contre mon vieux K6-2 fonctionne très bien comme serveur esd en réseau)

  • # GPLer ou ne pas GPLer...

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

    Un des développeurs viens de blogguer sur la question:
    http://4front-tech.com/hannublog/?p=8

  • # C'est fait.

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

    http://developer.opensound.com/
    Il y a néanmoins des informations un peu contradictoires au sujet des licences... espérons que ça sera clarifié.

Suivre le flux des commentaires

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