Articles précédents : Logiciel
- [57] Emacs 22 est déclaré stable
- [105] GPL3, TiVo ou TiVo pas ?
- [18] Géométrie dynamique avec CaRMetal
- [52] Mozilla finance un projet : 100 000 $ pour Democracy Player
- [28] Gérez vos dépôts subversion avec USVN
- [16] Sortie de NuFW 2.2, le pare-feu routeur authentifiant
- [51] Voyagez dans le temps avec Macfly 1.0
- [13] Libération du jeu Blades of Exile
- [86] Sortie de KDE 3.5.7
- [67] La communauté OpenWengo publie WengoPhone 2.1.0
Liens connexes
- Annonce sur un forum open solaris (179 hits)
- Annonce sur OSNews (190 hits)
- Open Sound System (312 hits)
- ALSA (195 hits)
- Open Sound System sur wikipedia (309 hits)
Dépêche modérée par
Dépêche éditée par
« 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.
![[en]](../../../images/en.png)
Annonce sur un forum open solaris (179 hits)-
Annonce sur OSNews (190 hits)
-
Open Sound System (312 hits)
-
ALSA (195 hits)
-
Open Sound System sur wikipedia (309 hits)
> Lire la dépêche (40 commentaires, moyenne: 2,8).
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.
*hum*
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 √λιi () le 08/06/2007 à 14:50. (lien). É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 Francois Revol (page perso, ) le 08/06/2007 à 23:32. (lien). É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 Laurent Moussault () le 09/06/2007 à 05:25. (lien). É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 Francois Revol (page perso, ) le 09/06/2007 à 10:20. (lien). É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 Aldoo (Jabber id, ) le 12/06/2007 à 11:20. (lien). É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 ?
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 pleiades () le 08/06/2007 à 13:43. (lien). É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 guix77 () le 10/06/2007 à 19:11. (lien). É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
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 chaperon () le 08/06/2007 à 14:06. (lien). É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 !--
man man, man !-
[^]Re: portaudio
Posté par Romain LE DISEZ (page perso, ) le 08/06/2007 à 14:38. (lien). É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 Julien () le 08/06/2007 à 16:30. (lien). É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 Matthieu C () le 08/06/2007 à 16:25. (lien). É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 Victor STINNER (page perso, ) le 12/06/2007 à 12:01. (lien). É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
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 José JORGE (Jabber id, page perso, ) le 08/06/2007 à 15:51. (lien). É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) ...
-
[^]J'suis sur qu'il a pas tout mis ...
Posté par Erwann Robin (page perso, ) le 08/06/2007 à 15:55. (lien). É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 Bench () le 08/06/2007 à 18:28. (lien). É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 Matthieu C () le 08/06/2007 à 21:50. (lien). É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 krumtrash () le 09/06/2007 à 08:32. (lien). Évalué à 1.Tu veux dire que le noyau n'utilise pas les optimisations MMX et SSE ?
-
[^]Re: Rien à voir: MMX/SSE
Posté par Vador Dark (Jabber id, ) le 09/06/2007 à 08:51. (lien). É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 Matthieu C () le 09/06/2007 à 08:57. (lien). É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 koyz () le 09/06/2007 à 14:40. (lien). É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 bubar () le 11/06/2007 à 13:09. (lien). É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 koyz () le 09/06/2007 à 18:53. (lien). É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 Antoine () le 09/06/2007 à 23:36. (lien). É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 Pierre Jarillon (page perso, ) le 10/06/2007 à 19:55. (lien). Évalué à 2.Je ne comprends pas pourquoi ce commentaire est noté négativement.
Est-ce quelqu'un pourrait expliquer ? Merci.-
[^]Re: La jungle des API audio sous linux
Posté par med (page perso, ) le 10/06/2007 à 22:55. (lien). Évalué à 3.Parce qu'il a déjà été donné deux fois juste au-dessus peut-être ?
-
[^]Re: La jungle des API audio sous linux
-
-
ALSA...
> 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 Matthieu C () le 09/06/2007 à 08:51. (lien). É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 Axioplase Ashi (page perso, ) le 10/06/2007 à 04:04. (lien). É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 pasBill pasGates () le 10/06/2007 à 05:41. (lien). É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 Francois Revol (page perso, ) le 10/06/2007 à 09:35. (lien). É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 ?
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 Francois Revol (page perso, ) le 12/06/2007 à 18:05. (lien). É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 Francois Revol (page perso, ) le 12/06/2007 à 18:10. (lien). É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...
Un des développeurs viens de blogguer sur la question:
http://4front-tech.com/hannublog/?p=8
C'est fait.
http://developer.opensound.com/
Il y a néanmoins des informations un peu contradictoires au sujet des licences... espérons que ça sera clarifié.
Cette page a été générée par Templeet en 0.1726s (dont 0.0459 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.