Pardon, mon post plus haut concerne KDE 4 et pas 3.4...
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 cmiramon . En réponse au journal Le son sous KDE (3.)4. É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.