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 jaroug (site web personnel) . Évalué à 3.
cf : http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php?company=G(...)
[^] # Re: ...
Posté par bmc . Évalué à 2.
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 doublehp (site web personnel) . Évalué à 1.
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 gnumdk (site web personnel) . Évalué à 2.
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 Stibb . Évalué à 0.
[^] # Re: ...
Posté par doublehp (site web personnel) . Évalué à 0.
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 jaroug (site web personnel) . Évalué à 3.
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 bmc . Évalué à -1.
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).
[^] # Re: ...
Posté par doublehp (site web personnel) . Évalué à 1.
# Arts
Posté par Stibb . Évalué à 1.
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 doublehp (site web personnel) . Évalué à -2.
[^] # Re: Arts
Posté par Cyberdivad . Évalué à 1.
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 Cyberdivad . Évalué à 1.
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 oliv . Évalué à 3.
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.