Journal Qualité des sorties son de oss/alsa/artsd/esd ?

Posté par  .
Étiquettes : aucune
0
13
sept.
2003
J'aimerais savoir ce que mon journal pense des qualitées sonores des différentes "sorties" possible sous linux : oss/alsa, artsd, esd ?

Je pose la question, parce que je trouve qu'avec oss (émulé par alsa) le son est mieux qu'avec artsd où j'ai l'impression que ça sature un petit peu (esd je n'ai pas essayé).
  • # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

    Je n'ai pas observé de différence de qualité, par contre il y a de belles différences de perf CPU : d'une part, l'émulation OSS par artsdsp (et sans doute également esddsp) bouffe trois tonnes de CPU, et d'autre part, avec MPlayer, j'ai ce résultat intéressant :

    * Pilotes OSS : son haché, pourri, vidéo fluide
    * Pilotes ALSA en direct : son nickel, vidéo fluide mais ralentie (bref, le CPU ne suit pas)
    * Émulation OSS sur pilotes ALSA : son nickel, vidéo fluide, le bonheur

    Ma théorie, c'est que le pilote OSS est pas top, que le pilote ALSA est bon mais que l'API ALSA bouffe du CPU, et donc que l'API plus simple d'OSS + le meilleur pilote d'ALSA = le meilleur des mondes, dans ce cas particulier.

    Ah, et par ailleurs, le DivX plein écran fluide avec un Pentium II à 275 MHz, merci MPlayer !

    Ma question à moi : ma carte son (AWE64) ne supporte qu'un seul accès à la fois, donc en pratique je mets une appli ALSA genre aRts et tout le reste derrière en client aRts ou en émulation artsdsp (qui bouffe du CPU). Est-ce qu'il y a moyen de faire accéder ma carte par deux applis ALSA en même temps ? J'ai bien cherché, j'ai pas trouvé, mais sais-t-on jamais ?
    • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

      Oui enfin ta théorie, je pense que ca depend aussi de ta carte son.

      J'utilise OSS et je n'ai aucun probleme. Au contraire, j'ai un sb 128 PCI et avec OSS, j''ai deux périphérique son, /dev/dsp et /dev/dsp1, bien utile pour le mixing hardware. Avec Alsa rien de tout ca.

      Une question, quelqu'un pourrait me dire si les drivers Alsa pour les audigy/sblive permet le mixing hardware(oss le faisait pour les sblive il me semble)
      • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

        Ah bein c'est marrant ca parce que moi aussi j'ai une sb pci 128 et j'ai jamais réussi a faire fonctionner 2 sons a la fois. genre quand je lance un mpg123 sur un fichier et quand dans un autre console j'en lance un deuxieme... bein le second attend que le premier soit terminé pour se lancer.

        Ca me fesait ca avec le pilote libre oss... Pareil avec alsa... la seule solution que j'ai eu c'est d'utiliser esd pour que plus d'un son ne sorte...

        Finalement j'ai essayé la démo des drivers proprio oss et ca marche nickel... Ca m'a tellement plu et soulagé que j'ai payé la license...

        ... Mais bon, pour la prochaine carte son que j'achete je ferai gaffe a bien choisir :)

        J'utilise OSS et je n'ai aucun probleme

        Si ce sont les drivers libre pourrait tu me dire quel est le nom du module exactement?, parce que j'aimerai bien comprendre :)
      • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

        Au contraire, j'ai un sb 128 PCI et avec OSS, j''ai deux périphérique son, /dev/dsp et /dev/dsp1, bien utile pour le mixing hardware. Avec Alsa rien de tout ca.

        Peut-être que tu l'as, mais que tu ne le sais pas ? Avec ALSA, le périphérique par défaut est hw:0,0 (premier canal de la première carte son). Tu as essayé hw:0,1 ?
      • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

        le drivers alsa te permet bcp plus de chose que le driver oss notamment sur les emu10k1 mais les outils n'ont pas encore tous etes crées apparement, sinon niveau devices hard tu peut utiliser aplay -l pour voir les peripheriques hard disponibles au travers de l'interface alsa (chez moi les memes 32 peripheriques que sous windows plus un acces au 8 peripheriques du chipset FX8010 (le dsp en lui meme).
        tu a aussi aplay -L qui te donne la liste des interfaces alsa disponibles

        voici un un exemple:
        aplay -D cards.pcm.front -f cd test2.raw
        aplay -D cards.pcm.rear -f cd test.raw
        aplay -D cards.pcm.center_lfe -f cd test3.raw

        va jouer 3 sources differentes en meme temps (ou en serie si dans le meme terminal bien sur) 3 fichiers de qualite cd sur separement les hp avants, les hp arriere et le hp central. (teste sur une sblive 5.1 en mode analogique avec DTT2200).

        si tu veut tu peut aussi lancer les trois (jsuqu'a trente deux) aplay sur le meme device (marche pour toute application alsa/ oss-alsa) pas besoin de plusieurs devices audio un seul suffit amplement.

        Et encore tout cela est teste avec la conf standard, en utilisant les asoundrc tu peut apparement tout modifier.
        Il reste le device surround40/surround51 que je ne sait pas utiliser (il doit falloir une source 5 entree).
    • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

      oula la y a des infos zarbis la dedans, pour artsdsp, c pas vraiment juste un serveur de son, il permet des transformations (mix en soft + sortie sur tel ou tel HP, il decode le mp3, etc j'amais essaye mais c les spec) donc qu'il pompe c bien possible. 2 EsounD ne propose pas d'emulation OSS il faut lui cause esound sinon pfuit (en device hard il gere oss et alsa) par contre il supporte l'envoi sur reseau, ca peut etre utile.

      Sinon pour ton test avec mplayer je ne pense pas que ce soit l'API alsa qui soit gourmande en cpu (vu que l'emulation OSS d'alsa utilise l'api alsa, en mode kernel d'accord mais bon) par contre je pense me rappeller que l'implementation de sortie alsa9 de mplayer est plutot ... pourrie.

      Sinon pour ton dernier point: http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3(...) section software mixing
      • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

        oula la y a des infos zarbis la dedans, pour artsdsp, c pas vraiment juste un serveur de son, (...)

        Tu as confondu artsdsp et artsd. artsdsp est un connecteur entre un client OSS et artsd qui s'attend à un client aRts, et je trouve qu'artsdsp bouffe pas mal de CPU. Je sais bien qu'artsd fait beaucoup plus qu'un serveur de sons de base. (Exemples personnels : écouter un stream basse-qualité sur le haut-parleur de gauche et le même en haute-qualité sur celui de droite, pour comparer ; rediriger tous les sons du système sur le canal de droite car le haut-parleur de gauche était mort).

        EsounD ne propose pas d'emulation OSS il faut lui cause esound sinon pfuit

        Et esddsp c'est quoi alors ?

        en device hard il gere oss et alsa

        Question importante pour moi : est-ce qu'il y a moyen choisir au moment où on lance esd, ou bien est-ce que c'est une option de compilation ?

        par contre il supporte l'envoi sur reseau

        Et aRts ne le fait pas ? Je croyais.

        Sinon pour ton test avec mplayer je ne pense pas que ce soit l'API alsa qui soit gourmande en cpu

        Je me suis mal exprimé (enfin, je voulais pas non plus vous pourrir de détails). Bref, je pensais que l'API d'ALSA pouvait être plus intense (plus d'appels par seconde) pour être plus précise, et que l'API d'OSS, même émulée, se contentait de moins d'appels par seconde. Et ce n'était, comme je l'ai dit dès le départ, qu'une théorie.

        je pense me rappeller que l'implementation de sortie alsa9 de mplayer est plutot ... pourrie.

        C'est ma foi fort possible. :-)

        Sinon pour ton dernier point: http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php3(...(...)) section software mixing

        MERCI MERCI MERCI MERCI MERCI MERCI MERCI (moi qui ai l'habitude de manger de la doc, j'ai honte d'être passé à côté de celle-là) MERCI MERCI MERCI MERCI
        • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

          Tu as confondu artsdsp et artsd. artsdsp est un connecteur entre un client OSS et artsd qui s'attend à un client aRts, et je trouve qu'artsdsp bouffe pas mal de CPU. Je sais bien qu'artsd fait beaucoup plus qu'un serveur de sons de base.

          arf possible, j'utilise pas trop arts, c juste ce que j'ai lu.

          (Exemples personnels : écouter un stream basse-qualité sur le haut-parleur de gauche et le même en haute-qualité sur celui de droite, pour comparer ; rediriger tous les sons du système sur le canal de droite car le haut-parleur de gauche était mort).

          d'ailleurs tes exemples personnel soit dit sans te facher ressembles bcp aux exemples 'personnels' sur arts que l'on lit partout sur le net en anglais comme en francais ...

          Et esddsp c'est quoi alors ?
          Une grosse merde pourquoi ? c juste un truc qui deroute les ecriture sur /dev/dsp vers lui meme en esound, donc oui bon on peut appeler ca une emulation oss.

          en device hard il gere oss et alsa

          Question importante pour moi : est-ce qu'il y a moyen choisir au moment où on lance esd, ou bien est-ce que c'est une option de compilation ?
          ca doit etre une options de compilation je me souvient plus trop mais je sais que la debian propose deux paquets libesd et libesd-alsa donc ca doit etre a la compil.

          par contre il supporte l'envoi sur reseau
          Et aRts ne le fait pas ? Je croyais.

          aucune idee c juste que je sais que esound le fait :)

          Je me suis mal exprimé (enfin, je voulais pas non plus vous pourrir de détails). Bref, je pensais que l'API d'ALSA pouvait être plus intense (plus d'appels par seconde) pour être plus précise, et que l'API d'OSS, même émulée, se contentait de moins d'appels par seconde. Et ce n'était, comme je l'ai dit dès le départ, qu'une théorie.

          mouai je reste sur mon point de vu le driver alsa9 de mplayer est tres mauvais (d'ailleurs c lui meme qui le dit quand il arrive plus a ecrire, meme si c parce que le fichier avi n'est pas telecharge completement :))

          MERCI MERCI MERCI MERCI MERCI MERCI MERCI (moi qui ai l'habitude de manger de la doc, j'ai honte d'être passé à côté de celle-là) MERCI MERCI MERCI MERCI

          de rien de rien, lit aussi mon post sur aplay -l et aplay -L ca peut etre utile :)
  • # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

    Bon il y a leger melange dans tout ca.

    1 tu a deux standards d'interface audio sous linux: OpenSoundSystem et AdvancedLinuxSoundArchitecture, le second etant bien plus avancé que le second.
    2 tu a ensuite pour ta carte des drivers différents possibles:
    ceux du kernel de base en OSS pour la plupart
    les versions payantes des memes drivers (enfin de la plupart) disponibles sur je sais pas trop quel site
    ceux fournis avec l'API alsa qui sont en regle générale meilleurs que ceux du kernel.

    Il faut tout d'abord tester tes drivers a ce niveau la avec des applications s'interfacant directementet eviter le software mixing etc ...
    Tu peut tester les outils fournits pour les interfaces (play/aplay) pour jouer des fichiers .wav non encodes pour tester les qualitées des sorties. Puis eventuellement ogg123 qui supporte les deux formats pour comparer.
    ecasound permet aussi la generations d'ondes sonores pour tester le materiel.

    3 enfin au dessus tu peut intercaler un serveur de son comme EsounD/aRts. Il faut savoir que EsounD se contente de mixer le son et de disposer d'une interface reseau, tandis que aRts propose de nombreux effets, le decodage mpeg et differents modes de mixages audio. aRts est une surcouche plus complexe avec plus de traitement sur le son ...
    Mon préféré c'est encore jackit un serveur de son temps reel qui peut necessiter quelques adaptation du kernel pour fonctionner a 100% mais
    qui se base sur la gestion temps reel du son.
    • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

      Posté par  . Évalué à 1.


      Il faut tout d'abord tester tes drivers a ce niveau la avec des applications s'interfacant directementet eviter le software mixing etc ...

      on peut aussi utiliser les pipe si on a pas de wav
      par exemple pour lire un cd
      cdparanoia -Z -- -1 - | aplay
      ou encore
      mpg123 -sq ...| aplay
      • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

        Posté par  . Évalué à 1.

        Mon driver alsa: ice1712 (DMX6Fire)
        En fait c'est assez étrange :
        lorsque je tester en passant par OSS émulé par ALSA avec mplayer ca marche sans problème. Le son sort sur les 5 cannaux.

        Si j'essais de passer directement par ALSA, j'ai des soucis :
        aplay -f cd test.mp3
        j'ai uniquement du souffle sur les 5 sorties

        Pareil ce que je comprends pas, il y a 3 devices, le dernier possède 6 subdevice :
        card 0: DMX6Fire [TerraTec DMX6Fire], device 0: ICE1712 multi [ICE1712 multi]
        Subdevices: 1/1
        Subdevice #0: subdevice #0
        card 0: DMX6Fire [TerraTec DMX6Fire], device 1: ICE1712 consumer [ICE1712 consumer]
        Subdevices: 1/1
        Subdevice #0: subdevice #0
        card 0: DMX6Fire [TerraTec DMX6Fire], device 2: ICE1712 consumer (DS) [ICE1712 consumer (DS)]
        Subdevices: 6/6
        Subdevice #0: subdevice #0
        Subdevice #1: subdevice #1
        Subdevice #2: subdevice #2
        Subdevice #3: subdevice #3
        Subdevice #4: subdevice #4
        Subdevice #5: subdevice #5

        J'ai essayer avec hw:0,1,0 ; hw:0,2,0 ; .. ; hw:0,2,6 : aucun son.

        Ma version de ALSA 0.96
        • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

          Si j'essais de passer directement par ALSA, j'ai des soucis :
          aplay -f cd test.mp3
          j'ai uniquement du souffle sur les 5 sorties

          Normal, aplay ne sait pas lire le mp3, tout juste le mpeg audio 1. Si tu veut vraiment lui envoye un format encode il faut comme ecrit dans le message precedent envoyer le resultat de la sortie de mpg123 en '-s' (ou il ecrit sur stdout le son en raw) a aplay en specifiant le format (cd la plupart du temps) ie
          mpg123 -qs test.mp3 | aplay -f cd

          Sinon je ne connait pas vraiment les DMX6fire, mais si elles gerent le hardware mixing alsa evrait le supporter. Pour tester lance plusieurs aplay dans differents terminaux pour commencer. Ensuite pour envoyer a l'un ou l'autre des HP etudie le resultat de 'aplay -L'
          • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

            Posté par  . Évalué à 1.

            Merci pour la redite.

            ça marche avec ".. | aplay -f cd", et avec -D"plughw:0,0,0".
            Je pense que ça marche avec le SPDIF (je n'ai rien pour vérifier réellement, mais le vumetre de Envy24Control indique qu'il y a quelque chose), les sorties sont "spdif" ou "iec958"
            par contre ça ne marche pas avec :
            "hw:0,0,0"
            "hw:0,1,0"
            "hw:0,2,0" à "hw:0,2,1"

            L'erreur qui me fait tiquer c'est avec -Dcards :
            ALSA lib confmisc.c:662:(snd_func_card_driver) cannot find card '$CARD'
            ALSA lib conf.c:3486:(_snd_config_evaluate) function snd_func_card_driver returned error: No such device

            donc je me dis que la configuration ne doit être bonne dans /usr/share/alsa :
            j'ai regarder il y a bien une configuration pour l'ice1712.
            Après je ne sais pas ou intervenir.
            • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

              Une question, pour essaye tu de faire -Dcards ? Parce que l'erreur que tu as c'est clairement que tu n'a pas d'entree 'cards' dans ta conf alsa. Tu a du oulbie une partie des entrees.

              Deuxiemement le driver alsa gere lui meme dans 95% des cas l'ouverture des sous peripheriques quand les autres sont indisponibles se fait automatiquement, contrairement aux drivers oss pour lesquel il faut specifier a la main le bon dsp.
              Donc pour acceder au deux sous devices ce serait plutot 'hw:0,0' et 'hw:0,1'. Mais meme dans ce cas je ne serait pas surpris que le driver ouvre tout seul l'un ou l'autre des devices suivant l'etat.
              • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

                Posté par  . Évalué à 1.

                Une question, pour essaye tu de faire -Dcards ?
                Parce que l'erreur affichée me semble la clé du problème.
                Ce que j'ai dans mon /etc/asound.conf :
                pcm.mixer {
                type dmix
                ipc_key 1515
                slave {
                pcm 'hw:0,0'
                }
                }

                pcm.ice1712 {
                type hw
                card 0
                }

                ctl.ice1712 {
                type hw
                card 0
                }

                En somme ce qui est indiqué partout dans les doc que j'ai trouvé.
                Qu'est-ce que je dois déclaré en plus, ou et comment ? (Un lien ou il y a la doc me suffit)
                En fait j'ai vu dans /usr/share/alsa/alsa.conf qu'il y a un lien vers /usr/share/alsa/cards, et je pensais que ce lien se faisait avec le nom du driver ?
      • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

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

        le cdparanoia ok eventuellement, mais pour tester la qualite d'une sortie audio
        le mpeg c moyen moyen, ce que j'ai oublie de dire dans le message ct de prendre un wav non encode (brut de decoffrage quoi, un truc qui a pas ete bidouiller).
    • [^] # Re: Qualité des sorties son de oss/alsa/artsd/esd ?

      Posté par  . Évalué à 2.

      > 1 tu a deux standards d'interface audio sous linux: OpenSoundSystem et AdvancedLinuxSoundArchitecture, le second etant bien plus avancé que le second.

      C'est curieux, moi, j'aurais plutôt dit que le second était beaucoup moins avancé que le second.


      Ok, je sors :)

Suivre le flux des commentaires

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