Dans le KDE-CVS digest d'hier [1], il y avait une intéressante rétrospective (voire un résumé) de ce qui s'est passé et (presque) décidé a la (star)aKademy (*) concernant le futur du serveur de son de KDE.
Lors de la news sur l'aKademy, le problème du son sous KDE avait été évoque. Votre dévoué serviteur avait d'ailleurs demandé quelques explications[2].
D'ailleurs l'aKademy m'avait permis de découvrir d'autres serveurs [de son,multimédias] que, en vrac, GStreamer[3] ou aRts : MAS[4] et NMM[5].
Je m'étais alors demandé quelles seraient les orientations prises dans le futur.
A priori, le remplaçant le plus avancé pour aRts (et donc celui qui serait logiquement choisi) est GStreamer.
Le seul problème est qu'il y a deux problèmes :)
- il est (quoi qu'on en dise) plutôt orienté GNOME (et ça hérisse un peu les devs de KDE, enfin c'est mon sentiment)
- il repose sur la glib, et du coup il faut des wrappers et autres bindings C++ pour le manipuler depuis KDE (c'est ma compréhension de tout cela, et j'atteins rapidement mon niveau d'incompétence)
La seule conclusion sûre : on savait ce qu'il n'y aurait pas dans KDE 4 (aRts) mais pas ce qu'il y aurait.
D'après les liens qui sont donnés dans le CVS-Digest, il semblerait que celui qui obtiendrait le plus de faveurs serait NMM.
Mais MAS n'a pas dit son dernier mot et il a des arguments de poids : principalement, il est 'supporté' par X.org [6]
Par contre : pas de module ALSA (bigre!) et pas de support d'OGG (re-bigre!).
Note : au contraire de ce que dit CVS-Digest : il y a bien un repository CVS accessible par le commun des mortels.
Personnellement, je suis assez fan de NMM. C'est du beau C++, il y a moyen de se faire plaisir avec tous les outils a disposition, même pour le programmeur du dimanche que je suis (ex: CVSWeb, Doxygen, de la doc en veux-tu en voila,... )
Bon ce n'est que mon avis, mais s'il y a des gens plus éclairés dans la salle, je suis preneur.
PS : un thread[7] intéressant sur une comparaison entre les différents protagonistes
(*) : C'était trop tentant, désolé :P
[1] : http://cvs-digest.org/index.php?newissue=sep242004(...)
[2] : http://linuxfr.org/comments/463964.html#463964(...)
[3] : http://gstreamer.freedesktop.org(...)
[4] : http://www.networkmultimedia.org(...)
[5] : http://www.mediaapplicationserver.net(...)
[6] : http://www.x.org(...)
[7] : http://www.mediaapplicationserver.net/public-mhonarc/mas-devel/msg0(...)
Journal Le son sous KDE (3.)4
25
sept.
2004
# ogg ?
Posté par animal_omega . Évalué à 2.
Par contre : pas de module ALSA (bigre!) et pas de support d'OGG (re-bigre!)."
ca me surprend que ca soit le serveur de son de supporter les differents formats audio ?
[^] # Re: ogg ?
Posté par jmfayard . Évalué à 8.
# Merci
Posté par Bouiaw . Évalué à 4.
[^] # Re: Merci
Posté par Vivi (site web personnel) . Évalué à 4.
[^] # Re: Merci
Posté par Sebastien . Évalué à 2.
Sans fausse modestie, y a vraiment pas de quoi casser trois pattes à un canard.
La preuve : même pas un troll qui pointe le bout de son groin dans les commentaires :P
Et puis je n'ai fait que suivre un lien, le traduire de l'anglais et butiner un peu du côté des liens que l'article de CVS-Digest donnait.
Ça peut tout juste faire un journal de seconde page, ce que j'ai fait. :)
# Le son dans 3.4
Posté par cmiramon . Évalué à 5.
L'entrée de ce journal présente de manière non exacte l'avenir multimédia de KDE 3.4. Pendant l'Akademy, plusieurs projets (GStreamer, NMM, Mas) ont organisé des présentations mais il n'y a pas actuellement de consensus massif pour l'un ou l'autre des infrastructures multimédias même si certains développeurs KDE sont fans de l'un ou l'autre projet.
L'impératif majeur pour le projet KDE tient dans le fait que l'infrastructure multimédia conserve la compatibilité binaire durant la durée de vie des séries 3.4 et aucun projet ne pouvait nous assurer celà.
Il a été décidé de créer un dorsal KDE, nommé KDEMM qui est déjà dans le CVS pour l'ensemble des infrastructures multimédia qui seront donc des greffons et que l'uilisateur KDE pourra choisir selon ses besoins. KDEMM propose une API simple correspondant à un usage relativement simple du multimédia. Les applications multimédias compliquées pourront continuer à être liées à une infrastructure particulière (GStreamer, Xine, MPlayer, etc.) si elles le souhaitent comme c'est le cas actuellement pour des programmes comme Kaffeine ou KMPlayer ou utiliser l'API de KDEMM, quitte à l'enrichir en la surclassant.
Les débats sont encore en cours sur ce que doit contenir KDEMM comme fonctionnalités. Les greffons qui sont en cours de programmation pour KDEMM sont : Akode (un serveur de son basique lié à Alsa ou Arts et interne à KDE) ; Arts, GStreamer, NMM, HelixPlayer. D'autres peuvent s'y ajouter car la liste n'est pas exclusive. Ce que proposera par défaut KDE n'est pas décidé. Cela demande des tests sur les solutions les plus robustes, avec des licences ne posant pas d'os et fonctionnant non seulement sous Linux mais aussi sur les différents BSD (ce qui est le principal problème d'Alsa).
Personnellement, la solution retenue me semble sage même si certains regrettent la création d'un nouveau filtre KDEMM et le fait que nous n'ayons pas fait un choix clair. Le monde du multimédia sur le PC est encore une cible fort mouvante. Il est par exemple bien difficile de dire aujourd'hui quels seront les codecs utilisés majoritairement dans 2/3 ans (libres, propriétaires) et quelle va être la part du travail qui sera réalisée par l'électronique des PC ou par le système d'exploitation. La position de KDE est donc relativement attentiste. Nous laissons le champ libre à l'expérimentation et nous attendons de voir quel projet va surpasser définitivement les autres et comment la technologie va évoluer.
Charles de Miramon
[^] # Re: Le son dans 3.4
Posté par Sebastien . Évalué à 3.
Le corps du journal ne parle que de KDE 4.
[...] mais il n'y a pas actuellement de consensus massif [...]
A la lecture des différentes mailing listes, le soir, au coin du feu, il m'avait semblé que les devs développaient une réaction épidermique à GStreamer.
Personnellement, je n'ai rien contre GStreamer, même si, comme je l'ai dit, j'aurais une petite préférence pour NMM, mais c'est plus au niveau de l'esthétique du code (et pour etre tout a fait honnete, je n'ai pas mis le nez dans celui de GStreamer).
Je dois dire que le temps que se donne KDE pour la réflection me semble aussi nécessaire que judicieux. Le but du journal était plus de faire découvrir les alternatives à aRts et GStreamer (puisque ce dernier commence a etre connu).
Cependant, concernant KDE 3.4, il me semble avoir vu passer qu'il serait possible que KDEMM soit distribué 'à part' pour pouvoir tester l'ébauche d'API, donc meme si le titre était démagogue, il n'était pas completement faux-cul.
Cela demande des tests sur les solutions les plus robustes, avec des licences ne posant pas d'os et fonctionnant non seulement sous Linux mais aussi sur les différents BSD (ce qui est le principal problème d'Alsa).
C'est pour cela que NMM me semble le candidat le plus sérieux.
Tant en terme de portabilité (tout le code spécifique à l'architecture est caché par des classes abstraites, donc a priori le seul probleme est le manpower) que de licence ((L)GPL).
[^] # Re: Le son dans 3.4
Posté par cmiramon . Évalué à 3.
Comme Sébastien, mon coup de coeur va à NMM (mais je suis pas du tout spécialiste de multimédia). La présentation à laquelle j'ai assisté durant l'Akademy était bluffante. L'intérêt du projet tient aussi au fait qu'il a été élaboré par deux professeurs d'informatique de l'université de la Sarre et qu'en bon projet universitaire, ils ont bien soigné l'architecture, les interfaces et la documentation. Le revers de la médaille, c'est que l'équipe de l'Université de la Sarre souhaite garder le leadership sur le projet et que l'on ne peut savoir ce qu'il adviendra du projet si les professeurs partent.
GStreamer semble être apprécié par ceux qui écrivent des lecteurs musicaux (Amarok, Juk) car il offre des fonctionnalités que l'on ne trouve pas ailleurs (abstraction pour les métadonnées d'un flux musical [auteur, titre, bitrate] ; synchronisation d'un flux visuel d'égaliseur avec le flux sonore).
MAS est un projet ancien qui a été développé par un hacker plus âgé qui gravite autour de X.Org. Le projet avance très lentement car c'est plus ou moins, le gagne-pain de Léon Shiman. Ce qu'il aimerait c'est que l'on choisisse MAS comme standard et qu'il en tire appui pour demander du sponsoring auprès du consortium X pour continuer le développement. Mais ce sont des pratiques aujourd'hui dépassées. Aujourd'hui, les projets du libre vivent dans une compétition ouverte et dans une course aux fonctionnalités. Ce n'est pas un comité qui choisit les standards et alloue les financements.
Akode est aussi intéressant. C'est beaucoup plus simple mais cela correspond aux besoins de 90 % de nos utilisateurs : écouter un MP3 ou un Ogg sur son client lourd Linux sans que cela empêche d'entendre les sons système.
Comme je l'ai dit plus haut, il n'est pas possible de trouver une infratructure qui satisfasse tout le monde. Du côté des utilisateurs, un musicien voudra une excellente synchronisation des flux sonores et la possibilité de gérer des cartes sons complexes. Il se tournera vers un noyau patché et Jack. L'utilisateur Lambda aura envie d'un système simple et incassable de type Alsa / Akode et évitera les usines à gaz de type GStreamer et NMM. Ceux qui veulent faire du son en réseau, par exemple des clients légers, utiliseront plutôt aujourd'hui NMM. Si on est un geek qui veut des options 'de la mort', GStreamer, permet de faire un effet 'pédale ouah ouah' sur l'ensemble des sons système ... Du point de vue des développeurs KDE, aucune infrastructure ne répond à tous les préréquisits. GStreamer, Mas et NMM ne sont pas développés à l'intérieur du CVS KDE. GStreamer dépend de GLib, bibliothèque que d'aucuns trouvent faire double emploi avec les fonctionnalités objet du C++ La politique de KDE est d'utiliser le moins de bibliothèques extérieures possibles car cela fragilise notre processus de développement.
[^] # Re: Le son dans 3.4
Posté par jmfayard . Évalué à 4.
GStreamer dépend de GLib, bibliothèque que d'aucuns trouvent faire double emploi avec les fonctionnalités objet du C++
Pas du tout, tu confonds GLib et GObject
GOjbect fait doublon avec les fonctionnalités objet du C++
Glib c'est une bibliothèque qui implémente les listes chaînées et autres, qui est petite stable et très bien documentée, et qui se retrouverait en pratique reprogrammée en moins bien et plus boguée dans chaque projet programmé en C.
Or si tu étais à Akademy, Trolltech y a dt que la philosophie de QT c'est de pouvoir accéder à toute une panoplie de bibliothèques programmées en C et de lui donner une API agréable en C++ (une API soignée étant au programmeur ce qu'une IHM soignée étant à l'utilisateur). Gstreamer rentre donc parfaitement dans la philosophie QT/KDE (une fois que les bindings adéquats sont réalisés. ça tombe bien, Scott Wheeler de JuK s'est proposé pour les maintenir)
La politique de KDE est d'utiliser le moins de bibliothèques extérieures possibles car cela fragilise notre processus de développement.
1) Cf paragraphe précédent. Regarde combien de bibliothèques extérieures en C QT/KDE utilisent.
2) Pas de chance, glib est déjà dans KDE, ironie du sort, par le biais de Arts
[^] # Re: Le son dans 3.4
Posté par Vivi (site web personnel) . Évalué à 2.
oui, enfin comme GObject dépend de Glib et qu'on trouve ça dans la tarball Glib, il a un peu raison quand même.
[^] # Re: Le son dans 3.4
Posté par Sebastien . Évalué à 2.
Encore une raison pour virer aRts[1].
Cela dit, "virer aRts" n'est pas nécessairement équivalent à "ne pas avoir de greffon supportant aRts".
Mais par défaut, j'aimerais bien ne plus avoir aRts dans un futur que j'espère pas trop éloigné.
[1] : http://www.arts-project.org/index.html(...)
[^] # Re: Le son dans 3.4
Posté par tanguy_k (site web personnel) . Évalué à 2.
Et la STL ca fait pas ca justement ?
> pouvoir accéder à toute une panoplie de bibliothèques programmées
> en C et de lui donner une API agréable en C++ [...]
> Gstreamer rentre donc parfaitement dans la philosophie QT/KDE
S'il existe deja des projets qui ont directement une API agreable en C++ je pense que c'est encore plus dans la philosophie Qt/KDE d'y regarder de plus pres avant de faire un choix qui aura beaucoup de poids.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.