Interview de Scott Wheeler à propos de kdemultimedia

Posté par (page perso) . Modéré par Jaimé Ragnagna.
Tags :
0
25
nov.
2004
KDE
L'avenir du multimédia sous KDE est encore bien flou.

Pour le moteur multimédia, il est maintenant sûr que Arts sera abandonné. Pour le remplacer, Gstreamer et NMM sont les mieux placés avec un léger avantage pour Gstreamer. Kdemm, une couche d'abstraction, est en cours de développement afin de permettre l'utilisation de plusieurs moteurs.

Du point de vu des applications, c'est très flou, Noatun ne rencontre pas le succès attendu, amaroK et Juk sont très populaires ainsi que kaffeine pour la vidéo. Il sera difficile de faire un choix.

Scott Wheeler dans cet interview donne son point de vue qui permet de nous éclairer sur tout cela. Nous apprenons dans cet interview que Arts sera abandonné pour des raisons techniques (latence trop grande) mais surtout car son créateur ne s'occupe plus du projet, que très peu de développeurs sont capables de le faire évoluer et aucun n'a une vision globale du projet lui permettant de le maintenir.

Devant cet échec, l'équipe KDE est prudente. Afin d'avoir le temps de tester les différents projets existants (Gstreamer, NMM, Helix, ...), une couche d'abstraction a été écrite : Kdemm. Cela permettra de voir les différents moteurs multimedia évoluer et de choisir le meilleur plus tard.

Pour les applications, c'est aussi très flou. Juk et amaroK sont deux applications phares sous KDE mais il sera difficile de faire un choix. Comme on a pu le lire sur KdeNews, les utilisateurs sont partagés. Certains sont conquis par toutes les fonctionnalités d'amaroK, d'autres préfèrent la simplicité de Juk. Ce dernier a l'avantage d'être déjà présent dans la distribution de base de KDE, la question est donc plus : doit-on sortir amaroK de kdeextragear (les applications KDE non-distribuées avec KDE) ?


http://developer.kde.org/~wheeler/juk.html


http://amarok.kde.org
(non disponible actuellement)

Pour la vidéo, le choix devrait se faire entre Kaffeine et Kmplayer (qui porte bien mal son nom).


http://kaffeine.sourceforge.net/


http://extragear.kde.org/apps/kmplayer.php
  • # 2-3 liens en plus

    Posté par . Évalué à 10.

    Il y aurait aussi 2-3 trucs intéressants sur les CVS-digests qui résumaient ce qui s'était dit lors de l'aKademy d'août 2004.

    NMM : http://cvs-digest.org/index.php?issue=oct12004(...)
    MAS : http://cvs-digest.org/index.php?issue=sep242004(...)
    GStreamer : http://cvs-digest.org/index.php?issue=oct152004(...)

    Bonne lecture.

    PS: et puis peut-etre ca aussi :
    https://linuxfr.org/~bins/15448.html(...)
  • # Kmplayer

    Posté par (page perso) . Évalué à 5.

    N'étant pas utilisateur de KDE, je n'ai pas compris tout de suite la remarque "". La première ligne du site web explique bien cela (je laisse quand même la description complète) :
    MPlayer/Xine/ffmpeg/ffserver frontend for KDE.

    As a stand-alone application it can:

    * play movies from file/url
    * play DVD
    * play VCD
    * play from a pipe
    * play from a TV device (experimental)
    * keep movie sizes ratio
    * movie progress slider
    * control arts volume
    * resize/fullscreen support
    * optional show mplayer output before and after a movie plays
    * configurable pattern matching
    * position slider
    * recording using mencoder
    * proxy settings from konqueror are used to set http_proxy environment variable
    * DCOP KMediaPlayer interface support

    It's also a KPart, making it possible to embed in konqueror (preview in Embedded KDE interface for MPlayer) or KHTML
    Additionally:

    * Javascript support

    Ca m'a l'air bien sympa !

    Haypo
    • [^] # Re: Kmplayer

      Posté par . Évalué à -1.

      > N'étant pas utilisateur de KDE, je n'ai pas compris tout de suite la remarque "".

      Quelle remarque? Tu veux dire la phrase 'qui porte bien mal son nom' ? Je trouve en effet que pour un player multimedia de kde, Kmplayer est un nom plutôt judicieux, surtout comparé à kaffeine (qui ressemble plus à un gestionnaire de machine à café ;) ).
      À l'origine, Kmplayer était une interface KDE pour Mplayer, mais il semble depuis qu'il se soit diversifié (Xine, etc.). C'est peut être ce point que souligne la remarque.... juste une supposition.

      PS: aurais-tu mis le doigt sur un bug de templeet concernant les phrases entre guillemets? faisons un essai:
      "Je vois dans se produire dans l'avenir proche une crise qui me perturbe et me fait trembler pour la sécurité de mon pays. Comme résultat de la guerre, de grandes entreprises ont été intronisées et une ère de corruption du pouvoir s'en suivra, et le pouvoir financier du pays s'efforcera de prolonger son règne en travaillant contre le peuple jusqu'à ce que toute la richesse soit concentrée dans les mains de quelques-uns et que la République soit détruite. Abraham Lincoln."
      • [^] # Re: Kmplayer

        Posté par (page perso) . Évalué à 5.

        Oui, c'est bien ce que je voulais dire, kmplayer, ca fait penser à : "Interface pour mplayer".

        Je n'ai découvert que hier que kmplayer pouvait utiliser xine alors que je connais l'existence de ce soft depuis un moment, d'ou ma remarque.
  • # RIP arts

    Posté par . Évalué à 5.

    J'aimais bien l'idée, ça permettait de faire pleins de bonnes choses, mais ça n'a jamais été utilisé comme il fallait.
    J'aimais bien par exemple en réseau pour avoir des terminaux qui "font" du son. Ca permettait d'avoir des applis même non kde sans support arts interne qui l'utilisent facilement à travers le réseau en faisant 'artsdsp appli'.
    Plus simple à mettre en oeuvre je n'ai trouvé que nas mais il réclame que l'appli le supporte en interne. Ca c'était bien avec arts.
    J'imagine que le problème c'est qu'il n'a jamais atteint une masse critique de développeurs. C'est dommage, c'est pas mal de temps perdu, parce que ce que pas de projets récents cherchent à atteindre il le faisait déja.

    Quant à noatun, créve!
    Je l'ai utilisé avec vraiment beaucoup de bonne volonté et il n'a jamais fonctionné correctement.
    Un exemple frappant, c'est que dans l'exemple au dessus d'un terminal réseau j'ai gagné du temps à utiliser xmms à travers artsdsp plutot que noatun toute seul parce qu'il n'a jamais réussi à comprendre ce que toutes les autres applis kde comprenaient, à savoir que le serveur de son était "ailleurs" et il lançait de lui même un artsd ou se plantait. Le comble!
    Alors si son auteur le trouve achevé, c'est qu'il y a eu un miracle depuis que je ne l'ai plus utilisé, c-a-d depuis amarok.
    • [^] # Re: RIP arts

      Posté par . Évalué à 3.

      Plus simple à mettre en oeuvre je n'ai trouvé que nas mais il réclame que l'appli le supporte en interne.

      C'est là que l'on peut voir l'avantage à utiliser Gstreamer. Gstreamer est déjà une couche d'abstraction. Il peut s'interfacer avec Alsa, OSS, ESD, Arts et plein d'autre. Donc pourquoi ne pas coder un plugin NAS pour Gstreamer.

      Je ne connais pas NMM donc je ne m'avancerais pas à faire une pseudo comparaison qui finirai surement en troll ;-)
      • [^] # Re: RIP arts

        Posté par . Évalué à 3.

        je n'ai rien contre gstreamer, mais il me semblerait judicieux d'avoir un vrai serveur de sons qui puisse faire la décompression, au lieu d'avoir de rajouter encore une couche d'abstration entre un serveur de son & l'application.
        à quand une normalisation d'un protocole de son indépendant du serveur de son, comme peut l'être le protocole X vis à vis de xfree/x.org ?
        Pourquoi pas une extension du protocole X qui gèrerait le son ? il me semble que MAS ou NMM peut s'interfacer avec un serveur X.
        • [^] # Re: RIP arts

          Posté par . Évalué à 8.

          Je te rejoins totalement sur la normalisation, ca permetrait aux devs de ce concentrer sur le serveur et pas réinventer la roue à chaque fois.

          Par contre sur une extension de X pour le son, la je suis radicalement contre, déjà je trouve que les players pour X ne devraient etre qu'une sur-couche graphique.

          Bref, le son sous linux n'a pas besoin d'un serveur graphique, n'allons pas créer des dépendances inutiles : modularité toujours !
        • [^] # Re: RIP arts

          Posté par . Évalué à 1.

          C'est certainement contraire aux intentions de l'équipe de KDE qui entend mettre fin aux dépendances par rapport à X11. (Il est prévu de faire en sorte que KDE ne dépende que de QT sur ce point).
    • [^] # Juk/Amarok : Faut-il vraiment choisir ?

      Posté par . Évalué à 4.

      Salut,

      Pour ma part, Juk et Amarok n'ont pas du tout la même cible.

      Juk est léger et simple d'utilisation.

      Amarok est plus lourd mais propose plus de fonctionnalités.

      Si je devais les comparer l'un et l'autre, je ne verrais pas trop l'utilité de Juk. (Bien sur, ce n'est qu'un avis. Je ne connais ces 2 logiciels que depuis peu de temps et non sous toutes les coutures).

      Juk un lecteur audio capable de gérer les musiques suivant divers critères et de créer des playlists.

      Amarok fait la même chose, mais permet de compléter certaines infos sur les albums/pistes (titre de l'album, nom exacte du morceau, jacquette, paroles, ...)
      Il effectue aussi des statistiques en fonctions du nombre d'écoutes, de la dernière date d'écoute, ... permet de les classés par préférences et ceux automatiquement.
      Il veille sur les changements dans les répertoires que l'on lui a demandé d'essayer, ...

      Bref vous l'aurez compris, je suis plutôt un défenseur d'AmaroK, et je ne vois pas pourquoi il n'aurait pas sa place parmis les paquetages de KDE. D'un autre coté, je ne vois pas pourquoi non plus, ceux dont les capacités de Juk suffisent, devraient voir leur programme retirés de la liste par défault de KDE.

      Mais ceux qui m'embêtes le plus dans KDE en général, c'est que justement dans un "paquetage", on retrouve plusieurs logiciels dont parfois un seul nous suffit. Pourquoi n'aurait-on pas le choix d'installer tel ou tel logiciel seulement plutôt que le gros bloc entier ?
      Je pense que la question devrait plutôt se situé dessus, ce qui laisserait à l'utilisateur final plus de liberté et de confort.

      Guile, un utilisateur très régulier de KDE même s'il lui trouve quelques défault.
      • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

        Posté par . Évalué à 4.

        Mais ceux qui m'embêtes le plus dans KDE en général, c'est que justement dans un "paquetage", on retrouve plusieurs logiciels dont parfois un seul nous suffit. Pourquoi n'aurait-on pas le choix d'installer tel ou tel logiciel seulement plutôt que le gros bloc entier ?
        Je pense que la question devrait plutôt se situé dessus, ce qui laisserait à l'utilisateur final plus de liberté et de confort


        KDE a toujours fourni les sources sous la forme de gros tarballs contenant de nombreuses applis. C'est un choix particulier qui peut se défendre (qui était même plutôt logique il ya quelques temps, qu'il est de moins en moins maintenant que de plus en plus de logiciels sont intégrés dans la version de base de KDE et que ça devient un joli bordel). Au moins, ça limite fortement les dépendances. Quand on voit ce qu'il faut faire pour installer Gnome (à la main), c'est une galère pas possible.
        Maintenant, si cette façon de faire ne convient pas aux utilisateurs, c'est aux distributions de découper les gros paquets d'origine en plus petits paquets. C'est justement ce qui est en train d'arriver (au moins pour celles que je connais) : Mandrake a déjà fait le pas depuis la version 9.2, pour Gentoo il existait la variable DO_NOT_COMPILE (qui n'était pas très conviviale) et ils sont en train de passer tous leurs paquets à une nouvelle version plus divisée. j'ai cru comprendre que la question était en train de se poser chez Debian également (mais là, je suis pas sûr). Pour les autres, je ne sais pas.

        Bref, la question était bonne et légitime, la réponse étant c'est en cours. :o)
        • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

          Posté par . Évalué à 4.

          j'ai cru comprendre que la question était en train de se poser chez Debian également (mais là, je suis pas sûr). Pour les autres, je ne sais pas.

          Sur debian ca fait bien longtemps que les paquets KDE sont divisés en plein de sous paquet ( a peu pres 1 par appli ).
          • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

            Posté par (page perso) . Évalué à 5.

            Non, sous debian, c'est pire que ca :)

            Pour ca, le Kde de la debian est génial, on install que ce dont on a besoin. Je dirais meme que le Kde de la debian est plus découpé que n'importe quel gnome sur n'importe quel distrib. Ils ont poussé le vice à l'extreme, c'est un peu troublant au début: genre t'install kmail et il n'a pas de support imap/pop par defaut :) Il faut faire un apt-get install kdepim-kio-plugins, idem pour le multimedia et pour kdebase.
            • [^] # vive le progres ?

              Posté par (page perso) . Évalué à -3.

              Genial !

              Enfin, tu es sur ? Tu appelles ca une fonctionnalite ? Donc il faut trois package (j'imagine que pgp/mime n'est pas fourni par defaut) pour installer kmail. C'est sur qu'avec ca, le linuxien debianiste se sent beaucoup plus intelligent:
              <<
              - t'as quoi comme distrib toi ? Moi j'ai une mandrake.
              - t'as une mandrake: c'est nul! Regardes, si tu veux kmail, tu as kmail directement. Moi, sur ma debian, j'installe kmail mais je n'ai pas kmail ! Il faut aussi installer les fichiers de config, l'interface graphique, le pop3, le imap et pgp/mime. Pour konqueror, il me faut 24 package (avec tous les kpart, sachant que khtml n'est pas fourni par defaut) pour l'installer, c'est quand meme beaucoup mieux que d'installer un seul paquett.
              - ben, je comprends pas ?
              - tu vois pas l'interet ? C'est dingue. Ma distrib, elle est _optimisee_ . Tu vois, si je veux kmail mais sans le support de l'interface graphique, du pop3 et de l'imap, je peux. Alors que toi, tu gaches 0.005 euro d'espace sur ton disque dur [1] ! Les distribs comme mandrake, elles t'installent toujours n'importe quoi quand tu ne leurs demande rien. C'est quand meme incroyable qu'on puisse pas choisir entre kmail avec et sans pop3+imap.
              - ah ouai, t'as raison. Je vais demander a Mandrake de splitter ses paquets comme debian. Mais si j'ai envie d'installer tout les logiciels de KDE, comment je fais ?
              - pas de probleme. Tu connais la liste de 112 logiciels inclus dans KDE, et tu insalles a la main les 453 paquets qui servent a les faire tourner. Tu vois, linux ca assure !
              - putain, c'est vraiment genial ce que tu me dis la. Quand je pense qu'avant, il me suffisait d'une dizaine de paquets pour obtenir pleins de logiciels. Comme j'etais naif.
              - et attends, tu iras au devant de nouvelles decouvertes. Grace a apt-get (que RMS benisse ceux qui l'ont developpe), les 1237 paquets de dependances de tes 453 paquets sont installees automatiquement.
              - putain, debian, ca assure vraiment un max !
              >>



              [1]: chiffre arbitraire en estimant que les options de kmail prennent 1 Mo et qu'un DD de 20 Go vaut environ 100 euro.
              • [^] # Re: vive le progres ?

                Posté par (page perso) . Évalué à 7.

                Quand on ne sait pas de quoi on parle, on s'écrase en principe ;)

                Tu sais ce que c'est un méta package?

                apt-get install kdepim et tu auras un kmail totalement fonctionnel.

                Mais bon, tant que tu y est, autant faire un seul package Kde avec tout dedans, ca sera plus simple, nan?

                Parce que moi, je trouve que y'a des trucs qui sont pas assez découpé. Genre konq-plugins ou j'aimerai bien avoir un package par plugin, ca m'eviterai de faire ca régulierement:

                rm -f /usr/share/services/fsview_part.desktop
                rm -f /usr/share/services/kuick_plugin.desktop

                Parce que moi, avoir des menus de 12 km de long, c'est pas vraiment le genre de truc qui m'interesse...
                • [^] # Re: vive le progres ?

                  Posté par (page perso) . Évalué à 4.

                  J'ai une bonne nouvelle pour toi, dans le CVS de KDE il y a maintenant possibilité de désactiver les extensions de Konqueror comme sous Firefox \o/

                  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

              • [^] # Re: vive le progres ?

                Posté par (page perso) . Évalué à 2.

                > un DD de 20 Go vaut environ 100 euro.

                Tu as regardé le prix des DD dernièrement ? Ou tu as oublié un '0' à "200" ? :-)
        • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

          Posté par . Évalué à 3.

          > Quand on voit ce qu'il faut faire pour installer Gnome (à la main), c'est une galère pas possible.

          Récupérer jhbuild ou garnome avant de lancer la compil, c'est pas trop compliqué hein ;) Ensuite si tu veux récupérer les trucs un pas un et les compiler à la main alors que t'as des scripts pour le faire à ta place, ou même des paquets précompilés avec ta distrib, libre à toi, mais viens pas te plaindre que c'est compliqué quand tu fais toi même le choix de te compliquer la vie.
          • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

            Posté par . Évalué à 1.

            Je comprends pas le rapport.

            Je dis justement dans mon message que c'est à la distrib de distribuer chaque logiciel de la façon qui lui plaît. Que les formats par défaut des projets (gros paquet pour KDE, plein de petites libs pour Gnome) ne doivent pas nécessairement être visible pour l'utilisateur.
            Donc, ton commentaire appuie le mien. C'est pas parce Gnome est livré de base avec plein de petits paquets que c'est comme ça qu'on le compile. Pareil pour KDE, c'est pas parce que c'est livré de base avec des gros paquets que c'est comme ça qu'on le compile.
      • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

        Posté par . Évalué à 2.

        Je re-réponds...

        Cette remarque me fait penser à un avis de Aaron Seigo sur son Blog :
        the topic of the blog: features are like drugs.

        when a feature is included in an application, some subset of the user base will become attached to it. very attached. they'll claim the need it, that they can't live without it. and fair enough, we come to grow comfortable with our configurations and tool sets.

        but then if that feature gets removed or altered, you can be certain that somewhere some user(s) exist who are going to be really upset. there are few features that don't have fans. it doesn't matter how stupid the feature is, it can't be taken back as easily as it's given.

        moreover, not all users like all features and options equally, just as not all people like all drugs equally. for instance, penicillin makes me break out in hives and pisses off my lungs (thank the goddess for tetracycline!) and marijuana just makes me drowsy and isn't particularly enjoyable to me. and so it is that some people just don't like certain software features.

        this means that when a feature is added, some subset of the user base will clamor for it to either be removed, changed or be made configurable. the challenge in removing or changing it has already been covered, so making it configurable is often the path of least flamage. this is how we get insanely large configuration dialogs and things like the clock applet. ug.

        now, i'm not advocating featureless software anymore than i advocate the outlawing of drugs. i am advocating that just as we should use drugs responsibly and often with consultation of an expert first, adding features is something to be done with much consideration.


        S'il existe plusieurs applications différents dans KDE pour faire plus ou moins la même chose, c'est qu'il suffit que chaque application ait au moins 1 fonctionnalité que les autres n'ont pas pour qu'il soit très difficile de supprimer cette application. La simplicité étant aussi "une fonctionnalité", il est toujours très difficile de supprimer une application des repository de KDE.
        • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

          Posté par (page perso) . Évalué à 2.

          Je vois pas pourquoi il faudrait supprimer Juk ou Amarok. Ok, les deux applications font a peu pres la meme chose. Mais dans la mesure ou elle le font bien, sont maintenues et plaisent aux utilisateurs, pourquoi en supprimer une ?

          Je suis un fervent partisan de la suppression des trucs qui marchent pas (noatun, arts, ...) mais juk et amarok, puisqu'ils plaisent, autant les garder.

          Pour info, kdeextragear, c'est pas la cinquieme roue du carosse, c'est des paquets KDE officiellement maintenus qui peuvent faire des release independantes de KDE. Cet ensemble de paquetage prend de plus en plus d'importantce, tout simplement parce que le nombre d'application developpee avec KDE et le nombre de developpeurs augmentent.

          Comme l'a fait remarque qq'un, les utilisateurs ne sont pas les memes. Pour mes parents, je mettrai plutot juk, car ca joue de la musique. Pour mon petit frere que ecoute de la musique 24/24, amarok convient mieux.
          • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

            Posté par . Évalué à 2.

            Car c'est chiant d'avoir 15 applications qui font la même chose a l'install de kde. Moi je serai plus pour un séparation de tout ça (comme font je crois les packageurs debian, et comme commencent a faire les packageurs gentoo).

            Perso je pense qu'on devrait proposer par défaut l'appli la plus légère, et a coté les applis avec un peu plus de features. Par contre je pense que ça poserai problème en rapport avec les interfaces dcop qui peuvent être utilisés par d'autres applis.
          • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

            Posté par . Évalué à 2.

            Mon propos n'était pas ici de savoir précisément si il faut préférer JuK ou AmaroK. Mais plus généralement la multiplication des logiciels pour faire "grosso modo" la même chose est le même problème que la multiplication des panneaux de configuration.
            Effectivement, KDE a décidé de donner la même réponse dans les deux cas : chacun fait comme il veut. Si un dev veut développer une nouvelle fonctionnalité/nouvelle appli, libre à lui. ET on ne supprime rien d'existant.
            On pourrait discuter à l'infini sur ce choix, ce que je ne ferais pas ici :)
            • [^] # Re: Juk/Amarok : Faut-il vraiment choisir ?

              Posté par (page perso) . Évalué à 4.

              La discussion a eu lieu recemment entre des developpeurs de KDE. Le consensus est que kdelibs + kdebase doit plutot fournir un seul logiciel par tache, dans la mesure du possible. KDE Extragear vient pour complementer.

              Sinon, la multiplication des logiciels sous linux pour faire la meme chose est un probleme de longue date. Ce qui est particulierement penible, c'est quand tu as 5 logiciels differents pour faire la meme chose, dont aucun ne marche correctement. Ce n'est pas le cas de juk / amarok donc je me rejouis de cette multiplicite qui a marche.
    • [^] # Re: RIP arts

      Posté par (page perso) . Évalué à 1.

      Pour arts aussi, je dirais "tant mieux".
      Je n'aime (ais) pas arts car il s'accaparait le son en permanence, même lorsqu'il n'était pas sollicité (contrairement à ESD par exemple, qui semble libérer le son quand il a fini de jouer).
      Concrètement, lorsque l'on fait par exemple un jeu vidéo, cela signifie qu'il FAUT obligatoirement prévoir un support arts, sans quoi les utilisateurs de KDE ne pourront pas avoir de son ! Heureusement qu'OpenAL est venu me sauver la vie (il supporte entre autre arts).
      • [^] # Re: RIP arts

        Posté par . Évalué à 2.

        Vraiment ? Jamais eu ce problème : Centre de configuration/Son et multimédia/Systèmes de sons → Suspendre automatiquement si inactif pendant 0 seconde ... Et voilà arts libère la carte dès que le son est fini. Bien évidemment ça ajoute de la latence lorsqu'un son doit être joué via arts.
        • [^] # Re: RIP arts

          Posté par (page perso) . Évalué à 1.

          hum... je n'avais pas cherché non plus (je n'utilise pas KDE). Le problème c'est que la suspension automatique n'est pas le choix par défaut (pas sur une mandrake y'a environ 1 an en tout cas), et que les utilisateurs de mon jeu avaient donc des problèmes de son sous KDE...
          • [^] # Re: RIP arts

            Posté par . Évalué à 2.

            Lore : Dark Horizon utilise un script : il passe artsd en mode suspendu ce qui libère le périphérique de son quelque soit le réglage de artsd. reste à vérifier le copyright , ce script contient des morceaux de code veant de loki , cela permeet peut être de déterminer sa licence...

            # Function to suspend the arts daemon. return 1 if the daemon is/was suspended,# 0 otherwise
            suspendArts()
            {
            local sleeptime=1 # seconds to sleep between retries
            local num_retries=3 # max number of retries

            local retry_count=0 # counter
            local status="" # output of artsshell command

            # do a basic test to see if the necessary programs are available
            status=`artsshell status 2>/dev/null`
            if [ ! $? -eq 0 ]; then
            # oh well
            return 0
            fi

            status=`artsshell status | grep "server status" | awk '{ print $3}'`
            while [ "$status" != "suspended" ] && [ $retry_count -lt $num_retries ]; do
            # sleep if this isn't the first try
            if [ $retry_count -gt 0 ]; then
            sleep $sleeptime
            fi

            # try a suspend
            artsshell suspend 2>/dev/null

            # increment count
            let "retry_count += 1"

            # get status again
            status=`artsshell status | grep "server status" | awk '{ print $3}'`
            done

            # is it suspended now?
            if [ $status = "suspended" ]; then
            return 1
            else
            return 0
            fi
            }


            il est appelé avec l'execution du jeu avec:
            # try to suspend arts
            suspendArts


            De mon côté j'ai eu aussi des expériences difficiles avec artsd : démarrage intempestif sous environnement gnome , rarement supporté par les jeux (artsdp n'aidait pas beaucoup pour quake2 et autres jeux basé sur ce moteur : un prblçme de mmap)

            En prenant de l'expérience , j'en conclus que artsd était le moteur de son le plus puissant (le suel à le battre aujourd'hui est NMM mais il n'est pas encore intégré aux ditributions). Par contre c'est le moins bien supporté par les applications non kde (rare sont les programmes à utiliiser ses fonctions de compatibilité, et artsd est en fin de compte capable de s'interfacer avec n'importe quoi).
            Autre problème : artsd est un serveur multimédia , le son n'est qu'une de ses fonctions. Hors rare au-delà du son son utilisation est marginale. Mais il n'a jamais été compatible avec les plugins de ffmpeg (mplayer) , LADSPA et en plus pour le son il ne gère pas le midi ...

            Donc un formidable outil qui a passé son temps à contourner tous les bugs/limitations des systèmes linux (Xv n'existait pas, ffmpeg était instable, la latence du noyau était énorme , les drivers oss ...)
            Alors que NMM qui a exactement le même objectif mais utilise tous ces projets externe a finalement été dévelopé en quelques mois , artsd avancait seul pendant des années ...
            J'espère juste que les développeurs de arts ne vont pas être amer et feront contribuer ces nouveaux projets de leur expérience, sinon nous finirons avec gstreamer comme seule api multimédia .

            Alban
      • [^] # Re: RIP arts

        Posté par (page perso) . Évalué à 3.

        T'as aussi artsdsp qui déroute les appels à OSS vers arts, et l'indispensable plugin dmix d'alsa qui permet à toutes les applis de jouer des sons en même temps, même avec les cartes qui normalement ne le gèrent pas.
  • # KDE sera user-friendly lorsque ce problème sera résolue.

    Posté par (page perso) . Évalué à 9.

    Linuxien débrouillard mais sans être expert, je reste encore sous

    Mandrake, que je bidouille en fonction de mes besoins.
    Mon utilisation devenat strictement bureautique avec un petit peu de dev, j'observe le desktop offert par KDE en tant que gestionnaire d'un réseau de 35 postes en entreprises, utilisés par toutes sortes d'utilisateurs de tous ages et de tous niveaux.
    Je me met donc dans la peau du end-user normal qui panique quand son icône Word a disparu, croyant qu'il a été désinstallé.

    J'observe sous cet angle le développement de KDE, ses avancées
    (géniales), ses avantages par rapport à XP (pour la première fois, je peux affirmer, depuis environ 6 mois, que KDE apporte des plus à XP sous certains aspects pour un utilisateur novice), ses ratés et ses manques.

    Parmi les gros manques, reste celui du son.

    Franchement, Billou et ses sbires doivent être mort de rires.
    C'est loin d'être au point...

    Loin de moi l'idée de critiquer, il faut rendre hommage au travail de
    nombreux développeurs talentueux, ya 4 ans je m'arrachais les cheveux avec oss, maintenant on a alsa et parfois, il arrive que Arts
    fonctionne.


    Sous windows, que l'on peu critiquer autant que l'on veut, le mixage du son n'est plus un problème depuis longtemps.

    Sous Linux, et dans le cas qui nous occupe KDE, il y a encore du travail. En effet, toujours dans cette logique de communauté qui me dérange quelque part en tant que Républicains français (très) méfiant vis à vis du communautarisme, mais aussi en tant que passionné de primatologie/ethno/anthropologie tout à fait réaliste quand à la primalité et donc l'attractivité de ce type de structures sociales, le concept "le but est de faire un serveur de son pour KDE et les appli multimédia de KDE, et les autres on s'en tappes" m'échauffe assez le sang.
    J'entend déjà les sarcasmes de mes amis windowsiens : "tiens c'est dingue, faut reconfigurer le son selon que tu utilise KDE, Gnome, etc..."

    C'est LE gros problème.

    On ne peut demander à un utilisateur novice de choisir entre la couche d'émulation oss d'alsa, alsa lui même, arts, ou je ne sais quoi d'autres, comme je suis obligé de le faire.
    Personnelement, cela ne me dérange pas, c'est juste un contre temps, et kill sur le terminal. Mais cela n'est qu'à la porté de power-user comme nous.
    Il est déjà génant pour un novice de devoir choisir entre quinze
    applications offrant le même service, si en plus il doit utiliser le
    terminal...

    <pas tapper> Je sais, avoir plusieurs appli pour le même service est un plus, une liberté que comme vous j'apprécie et dont je n'aimerai pas me passer.
    </pas tapper>
    Mais ce n'est pas le cas d'un novice qui veut un logiciel pour lire ses
    DVD, un logiciel de gravure, un traitement de texte, un navigateur, son logiciel de mail et son logiciel de messagerie instantané.
    Ce sont des gens qui sont perdu quand on a déplacé un icône de 50 pixels dans une barre d'outil, alors leur proposer 3 lecteurs vidéo, 2 navigateurs, etc... leur fait peur.

    C'est d'ailleurs pour cela que je milite auprès de Mandrake, puisqu'ils destinent leur distrib à cette population (enfin il aimerait bien) de poser la question à l'utilisateur, lors de l'installation, de son niveau de compétence et quelques autres questions permettant d'adapter le desktop à l'utilisateur.
    Je répondrait, nous répondrions que nous sommes expert, ce faisant j'obtiendrai un bureau avec un terminal dans ma barre de tâches, plusieurs logiciels pour chaque fonctionnalitées, etc...

    Le novice n'aurait aucun choix parmi les applications répondant à
    certaines fonctionnalitées. Il faudra à la base faire le choix corneilien des logiciels. Tout au plus pourrait-on lui proposer un
    présentation vidéo l'informant de l'existance de plusieurs logiciels,
    de leur fonctionnalités propre, avantages/inconvéniant lui permettant de faire un choix (mais pas au début).

    <parenthèse>
    Je crois beaucoup aux présentations vidéo pour démocratiser linux. Je serai prêt à en faire quelques unes si j'avais sous la main un logiciel fonctionnel me permettant de faire une capture vidéo de mon desktop. Il en a été fait un, mais il déconne complètement et est à peu près inexploitable...
    </parenthèse>


    Il faut donc que l'ensemble des communautés se mettent d'accord, quitte à user de couches d'abstractions sur un serveur de sons efficasse permettant de faire fonctionner l'ensemble des applis.
    gstreamer est surement très bien, Jack à l'air génial, etc... Je ne
    connais pas les technologie.

    Tant que certains problématiques de ce genre ne seront pas solutionnées(Visualiser automatiquement les partages samba dans le kdfm, visualisateur d'images gérant les galleries absent (enfin peut êtr que depuis...), les icônes d'applications instalées n'appraissant pas (toujours) dans le menu K, etc...), Linux ne sera pas prêt pour le destop et donc n'investira pas l'entreprise (où le son est un problème très secondaire) et donc...

    C'est vraiment dommage, parce que toutes les briques sont présentes pour faire un OS mieux qu'XP. Mais entre lmes batailles entres communautés, le fait que les employés de Mandrake n'ont manifestement jamais vu une PME typique de leur vie, que l'implication partisane aveugle, ça limite...

    'Fin voilà

    Perso je travaille pour la suite ( http://isaacos.loria.fr(...) ), ça ne
    m'angoisse plus.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.

      Posté par . Évalué à 3.

      « Je crois beaucoup aux présentations vidéo pour démocratiser linux. Je serai prêt à en faire quelques unes si j'avais sous la main un logiciel fonctionnel me permettant de faire une capture vidéo de mon desktop. Il en a été fait un, mais il déconne complètement et est à peu près inexploitable...
      »

      C'est xvidcap le logiciel que t'as testé ? (http://xvidcap.sourceforge.net/(...))

      En ce qui concerne ta distrib idéale, ton pb de démon pour le son, ... ubuntu me semble pas mal au niveau du "une seule appli proposée par tâche". Comme c'est que des applis gnome, ça résoud le pb du démon pour le son au passage ;)
      fedora a l'air de regarder un peu du côté de alsa/dmix pour voir si y a moyen de faire des choses intéressantes de ce côté là. Sinon t'as aussi une solution au pb des démons différents, c'est d'utiliser une carte son potable et de pas utiliser de démon pour le mixage ;)
      • [^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.

        Posté par (page perso) . Évalué à 2.

        c'est bien xvidcap, oui
        C'était une horreur, impossible d'enregistrer un vidéo d'une définition supérieur à 320x200. et je ne suis malheureusement pas assez bon en dev pour l'améliorer :(

        Il me semble que ce n'est pas dans le débat "tel distrib fait ce que tu veux, etc..."

        Je veux être réaliste et à mon avis, seule Mdk, ne serait-ce que parce que c'est une entreprise et qu'ils ont choisi de s'adresser à la niche "Linux pour le desktop" est à même d'avoir les reins assez solide pour proposer une distribution cohérente :-)
        Je pense aux formidable travail de mdk sur l'installation, sur le "panneau de configuration" (j'utilise l'expression windowsienne à dessein), etc...
        Cà n'est pas contre les distrib alternative, mais je pense que seule une boite avec des moyens, en sus de la communautés peut proposer une distrib crédible.

        Quand à mes problèmes de sons, je m'en contente tout à fait, comme je le disais, je bidouille quand il ya à bidouiller, j'arrive toujours à m'en sortir.
        Mon propos est que le novice, il installe son linux, ça doit marcher, point.

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.

          Posté par . Évalué à 5.

          Oui, et mon propos, c'est que c'est en partie le boulot de la distrib de faire en sorte que ça marche quand tu l'installes. Et pour ça ubuntu au moins (peut être fedora, je sais pas j'ai pas trop testé) seront peut être plus satisfaisants de ce point de vue là. ubuntu et fedora sont toutes deux soutenues par des entreprises puisque ça a l'air de te tenir à coeur...
      • [^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.

        Posté par . Évalué à 8.

        le tout dernier VLC 0.8.1 a une nouvelle feature "Stream your desktop" :-)

        * New screen capture input plugin for X11, Win32, BeOS and Mac OS X
        (Stream your desktop)


        qui te permet de capturer donc ton desktop et de la streamer vers le réseau ou vers un fichier :)
    • [^] # Re: KDE sera user-friendly lorsque ce problème sera résolue.

      Posté par (page perso) . Évalué à 2.

      Sous windows, que l'on peu critiquer autant que l'on veut, le mixage du son n'est plus un problème depuis longtemps.

      Quand on utilise directx, mais sinon, sous win9x, les cartes avec un seul cannal ne jouaient qu'un son à la foix.
      Et puis, dmix ça doit bien avoir deux ans. Et avant, on s'en sortait, avec la sortie alsa de sdl et artsdsp (sans parler de ceux qui ont acheté 20¤ une carte son multicanaux).

      le concept "le but est de faire un serveur de son pour KDE et les appli multimédia de KDE, et les autres on s'en tappes" m'échauffe assez le sang.

      Arts n'as pas été conçu pour KDE, même si ce dernier l'a popularisé. Il existait avant et n'est pas utilisé que par les applications KDE.
  • # mouais

    Posté par (page perso) . Évalué à 4.

    Moi je me pose quand même la question de l'intérêt de développer une couche d'abstraction au dessus de GStreamer pour pouvoir utiliser "plusieurs moteurs". GStreamer est déjà en soit une couche d'abstraction, celà ne fera qu'allourdir l'ensemble je trouve.
    • [^] # Re: mouais

      Posté par (page perso) . Évalué à 7.

      arts aussi était une couche d'abstraction or personne n'avait prévu qu'il n'allait plus être maintenu et personne chez KDE ne peut le maintenir.

      Depuis, KDE ne veut pas dépendre d'un produit externe sur lequel elle n'a pas la main (dans le sens "connaissance" pas "contrôle").

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: mouais

        Posté par (page perso) . Évalué à 5.

        Je pense que rajouter une API au dessus de gstreamer, ca va aussi permettre d'avoir une API vraiment Kde compliant. Apres, cette couche d'abstraction, elle est deja dans amaroK (en gros) et je trouve pas amaroK plus lent qu'un autre.
  • # DirectX

    Posté par (page perso) . Évalué à 2.

    En fait, le problème essentiel ici est qu'il n'y a pas pour le moment d'équivalent à DirectX sous Linux. Actuellement, on a OpenGL pour la 3D et (si je ne me trompe pas) SDL pour Direct2D. Mais DirectSound, DirectShow et co. n'ont rien.

    Il serait temps d'avoir un système unifié (un peu comme on a Xorg pour l'affichage graphique) pour les applications multimédia. Ca simplifierait vraiment les choses pour les développeurs et les utilisateurs.
    • [^] # Re: DirectX

      Posté par . Évalué à 4.

      *Kof Kof* hum, les premières lignes de libsdl.org :

      "Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer."
      • [^] # Re: DirectX

        Posté par . Évalué à 4.

        Oui, c'est ce qu'il dit, SDL ça fait direct2d, un peu directsound et directinput (sdl c'est très bas niveau), mais pour directshow on n'a pas grand chose. On veut gstreamer est assez proche de directshow au niveau conceptuel et vise à apporter ce layer manquant aux unix...
        • [^] # Re: DirectX

          Posté par . Évalué à 2.

          tres bas niveau????

          tu veux rire!!!!
          bon, p-e pour le son et la gestion des events, mais pour l api graphique, c est un vrai cauchemar pour faire autre chose que des jeux.

          Je travaille pour une compagnie qui tente de porter sa lib graphique sous linux, on prennait sdl au debut, finalment, on a pété un plomb et tout recodé l'affichage. Le simple fait de ne pas pouvoir avoir du multi display est une horreur. Ils ont voulu avant tout etre ultra portable, le problème, c que si une architecture ne suportait pas telle chose, toutes les autres ne l ont pas non plus. Il faut voir aussi l'interface de l'overlay de SDL... a comparer avec Xv et DirectX, il n'y a pas grand possibilite de manoeuvre (tout de meme bravo pour l'overaly software, c rapide)

          finalement , pour revenir notre code, sorry, ils ont pas voulu qu on le rendre gpl... mais j avais commencé le tout chez nous pour montrer au boss et forcer la migration, des que je clean ca un peu, je rend ca publique, ca fairait un bel ensemble avec la sdl courrante, notament permettre plusieur display (fenetré, X only)
    • [^] # Re: DirectX

      Posté par (page perso) . Évalué à 2.

      mais si on a deja, un executable windows (directx+directshow), et wine

      /o\
    • [^] # Re: DirectX

      Posté par (page perso) . Évalué à 2.

      Pour le son y'a ca : http://www.openal.org/(...)
  • # Rediriger son windows vers pc linux avec arts

    Posté par . Évalué à 1.

    C'est peut etre un peu HS mais est ce que qqn sait sil est possible de rediriger le son dun pc ss windows vers un autre PC mais ss linux en utilisant arts (ou autre) comme on pourrait le faire ss linux tres simplement avec arts des 2 cotes.
    Le but est dutiliser mon ensemble 4.1 qui est branche sur mon PC sous linux depuis mon portable sous windows (quand je joue ^_^, sinon je meternise pas ss cet OS :p).

Suivre le flux des commentaires

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