Forum général.général avoir le son de plusieur aplis ???

Posté par  (site web personnel) .
Étiquettes :
0
30
sept.
2004
j utilise actuelement esd sur OSS pour que mes differents apli puissent jouer du son en meme temps

le probleme est que toutes les aplis dont j ai besoin ne suportent pas ESD; j ai tente une migration vers ALSA, et quand une apli utilise la carte son, les autres ne peuvent plus y acceder;

je cherche une solution pour jouer plusieur sons en meme temps, et que ce soit transparent pour les aplis; j utilise actuellemtn en meme temps xmms mplayer et gaim, et je voudrais ajouter gnomemeeting et un autre voip, mais les logiciels de voip refusent esd, cause il est pas full duplex.

Ce qui me tue, c est que sous windows, il a toujours ete possible de jouer 36 trucs en mem temps, depuis w98 ( si il eu ete possible de lancer 36 aplications en meme temps sous windows ^^ ) - alors que sous linux faut des ruses de sioux et ca marche pas toujours. ( oui ca ca m ennerve )

Ma carte son est une VIA97c integree a mon portable .
  • # ...

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

    Il suffit d'utiliser le plugin 'dmix' d'alsa pour ca, ce n'est pas quelque chose à rajouter, juste à configurer dans ton .asoundrc.

    cf : http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php?company=G(...)
    • [^] # Re: ...

      Posté par  . Évalué à 2.

      Sauf que ça c'est la théorie, et qu'en pratique, avec un .asoundrc nickel de derrière les fagots, ça n'a jamais fonctionné réellement sur mon portable équipé d'une carte son intégrée Intel qqch.

      Le problème est que les applications doivent être codées presque spécialement pour ça. Par exemple, le plug-in ALSA de XMMS essaye d'ouvrir en dur la première carte son ("hw:0,0" ou une chose de ce genre), et que soit il y arrive et il squatte la carte, soit il n'y arrive pas (par exemple parce qu'il y a un multiplexage dmix dessus) et il se chie dessus.

      Je trouve que cette solution ne fait que déplacer le problème. Je me demande bien pourquoi l'API d'Alsa ne semble pas prévoir de rendre ça totalement transparent pour le développeur (style tu ouvres hw:0 et le pilote ALSA se débrouille pour savoir s'il faut multiplexer ou pas).
      • [^] # Re: ...

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

        Je me demande bien pourquoi l'API d'Alsa ne semble pas prévoir de rendre ça totalement transparent pour le développeur

        enfin quelqu un qui aborde mon 4e paragraphe.

        mais moi je vais plus loin : pourquoi sous linux c est a l apli de gere ca ? pourquoi le driver alsa pourrait pas simplement suporter lui meme le multiplexing ? MS W98 le fesait ... c est que ca doit pas etre bien sorcier quand meme. Il suffit de coder un driver qui accepte plusieurs ouverture en ecriture simultanees, ajuster les debits, mixer le tout et basta ...

        y a un empechement majour sous linux ou c est juste la flemme des codeurs ?

        quand ALSA est sorti pour 2.4, les rumeurs disaient que c etait une revolution que 2 aplis puissent acceder a la carte son en meme temps sous linux ( sans ESD) ... je test la chose plus de 2 ans apres sa sortie, et ca marche pas. Comprenez mon agacement.
        • [^] # Re: ...

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

          "pourquoi le driver alsa pourrait pas simplement suporter lui meme le multiplexing ? MS W98 le fesait ..."

          Faux, sous windows, c'est logiciel comme arts et esd, meme qu'avec windows 2003 t'as meme le droit de le couper si tu veux :)
          • [^] # Re: ...

            Posté par  . Évalué à 0.

            sauf que les API sont figé et on n'a pas a faire une sortie pour le driver alsa ou arts ou esd, on fait sndPlaySound et basta...
          • [^] # Re: ...

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

            Faux, sous windows, c'est logiciel

            en tant que programmeur, pour moi, ALSA c est aussi un logiciel.

            Ca ne change rien au probleme que sous windows c est transparent pour l apli, ca ne necessite pas de conf particuliere, et c est full duplex; je te reitere ma question :

            pourquoi ALSA ne pourrait pas faire ce que MS fait depuis 6 ans ?
      • [^] # Re: ...

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

        Je pense que c'est faux ce que tu dis, les applications utilisant alsa, prennent la sortie spécifié ou la sortie par défaut, il suffit d'ecrire la configuration par defaut en utilisant le plugin dmix chez moi ca donne :

        pcm.!default {
        type plug
        slave.pcm "dmixer"
        }

        pcm.dsp0 {
        type plug
        slave.pcm "dmixer"
        }
        pcm.dmixer {
        type dmix
        ipc_key 1024
        slave {
        pcm "hw:0,0"
        period_time 0
        period_size 1024
        buffer_size 8192
        rate 44100
        }
        bindings {
        0 0
        1 1
        }
        }

        ctl.mixer0 {
        type hw
        card 0
        }

        Et donc beep-media-player fonctionne sans rien avoir spécifié, de même pour totem, mplayer et gaim

        bmp :
        [ALSA]
        audio_card=0
        audio_device=0
        buffer_time=500
        period_time=50
        use_user_device=TRUE
        mmap=TRUE
        mixer_card=0
        mixer_device=PCM
        user_device=default

        totem :
        audio.alsa_hw_mixer:0

        mplayer :
        ao=alsa

        gaim :
        *j'ai pas trouvé*

        J'ai réglé un fichier de conf proprement et tout fonctionne et peut fonctionner en même temps. Notez que la config est propre à ma carte je sais pas si c'est utilisable sur toutes les cartes.
        • [^] # Re: ...

          Posté par  . Évalué à -1.

          Avec exactement le même .asoundrc, bmp et rhythmbox ne peuvent cohabiter. Seul le premier qui est lancé accède à la carte son. À noter que aplay permet d'avoir différents sons simultanés (donc ça fonctionne).

          Je précise que j'ai laissé bmp avec le plugin de sortie OSS (parce que je trouve qu'il fonctionne mieux que le ALSA au niveau du buffering). Cela semble être à ce niveau là que ça bloque (avec le plugin de sortie ALSA ça fonctionne), mais si c'est ça, les développeurs de l'émulation OSS d'Alsa ont été un peu zêlés en intégrant même les défauts d'OSS :)

          Je répète donc que, pour une raison ou pour une autre, ALSA n'est pas totalement transparent pour le développeur au niveau de toutes ses fonctionnalités, car il nécessite d'avoir un plugin de sortie spécifique ALSA.

          Allez, dites-moi que je me trompe et qu'il y a une solution (d'autant plus que nombre d'applications n'ont pas de plugin ALSA).
  • # Arts

    Posté par  . Évalué à 1.

    apt-get install arts
    tu configures ton noyau pour qu'il utilise alsa (alsaconf), et hop en utilisant les plugins de sortie vers arts (xmms en a un, les applications kde semblent utiliser directement arts quand disponible, ou au pire en indicant de lancer la commande artsplay pour jouer un son (notament dans psi), la tu auras plusieurs sons en meme temps.
    alsawrapper lance le serveur en timecritical.

    Perso, chez moi le son chie un peu de temps en temps quand je change de bureau virtuel ou quand je déplace une fenetre je ne sais pas si ca vient de arts ou de alsa...
    • [^] # Re: Arts

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

      deja je tu parles de plugin ... et j ai explicitement demande a ce que ce soit transparent pour l apli ... ensuite je n ai pas vu que gaim ait ce plugin ... puis je t assure que gnomemeeting ne l as pas. Enfin je doute fort que ton truc supporte le full duplex => si j ai bon, aucune apli voip ne le suportera jamais.
      • [^] # Re: Arts

        Posté par  . Évalué à 1.

        Il n'a pourtant pas tort.

        Actuellement, à moins d'utiliser l'option dmix d'alsa décrite plus et supportée par une petite poignée d'applis, le seul moyen d'avoir plusieurs sons en meme temps est de passer par un serveur de son. Les connus sont :
        - arts, utilisé en standard par kde (plus pour longtemps parait-il)
        - esd, utilisé par gnome
        - jacks, pour les exigents, notemment en latence : applications audionumériques, vidéos, etc.

        Pour info, arts est parfaitement full duplex (si le pilote alsa de ta carte son le permet) et Gaim sait l'utiliser. Mais je serais incapable de configurer arts sans passer par le panneau de config de kde, pas pratique si on ne l'a pas.

        Perso, je suis plutôt orienté jacks, parce qu'alsa avec sa demi-seconde de latence, ca le fait pas en enregistrement audio-numérique multipistes. Je trouve aussi que c'est le plus complet (le programme de config en qt offre des possibilité de fou), surtout question cas bizarres (deux cartes, config midi spéciale, etc.) jacks et arts peuvent être tous deux empilés l'un sur l'autre.

        Malheureusement, tout ça n'est pas prêt d'être transparents pour les applis. Le plus anciennes passent par oss et bloquent /dev/dsp sans se poser de questions. D'autres ont choisi d'utiliser un système de plugins pour prendre en charge plusieurs serveurs de son au choix. Quelques unes fonctionnent avec alsa seulement, etc.

        En fait, le seul moyen pour parvenir à une transparence parfaite pour les applis est d'avoir une carte alignant les canaux comme des petits pains dans une boulangerie, ainsi le mixing est hardware.

        Encore, tout çà est encore simple, tu n'imagine pas comment j'en ai chié avec ma carte son usb qui n'est pas toujours branchée et que je ne peux par conséquent pas utiliser avec arts (un système de sélection automatique de la carte par priorité au lancement d'arts aurait été cool). Et les device /dev/dsp* qui s'inversent selon que la carte usb est connectée au démarrage ou pas.

        Sinon, je ne croie pas que Windows 98 gère simplement l'accès concurrent aux cartes son, sauf pour les applis passant par directx, sinon c'est tintin aussi. il a fallu attendre que la plupart des applis utilise l'api directx pour que ça soit mieux. Comme sous Linux, y a plus de choix, au final c'est un peu plus le bordel, c'est tout, mais les solutions sont là.
        • [^] # coquille.. Re: Arts

          Posté par  . Évalué à 1.

          Perso, je suis plutôt orienté jacks, parce qu'alsa avec sa demi-seconde de latence, ca le fait

          Je voulais évidemment dire arts, et non alsa. Désolé, j'ai tapé un peu vite, c'est bientôt la fin de la journée :-)
    • [^] # Re: Arts

      Posté par  . Évalué à 3.

      Le problème avec arts, c'est que tu te retrouves avec des applications (heroes of might and magic III ou Freeciv, par exemple) dont le son est décalé de une seconde par rapport à ce qu'il devrait être (ce problème est très fréquent si on en croit google, et la réponse est toujours: "n'utilisez pas de daemon").
      De toutes les solutions que j'ai essayées (arts, esd, OSS seul et alsa seul), seul OSS m'a donné la possibilité de son correctement synchro et partagé entre les applis. (sur une Mandrake 10.0)

Suivre le flux des commentaires

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