Dans un message récent, il y avait un petit schèma qui résume à lui tout
seul mon problème, c'était celui-ci :
> Ogle XMMS
> \ /
> ARTS
> |
> ALSA
> |
> noyau
Ça impose de configurer toutes les applis pour qu'elles passent par ARTS.
Existe-il un autre serveur de son, pour lequel cette étape ne serait pas
utile ? Un truc, genre, qui créerait un /dev/vrai_dsp, qui utiliserait
lui-même /dev/dsp, et donc que toutes les applis croyant s'adresser à la
carte son s'adresseraient au serveur de son, qui se demerderait ensuite
pour mixer ça.
Ou peut-être n'est ce que un mixeur, qu'il me faudrait. Je ne sais pas si
ça fait vraiment une différence.
En résumé, je cherche un truc qui me permette de jouer des sons depuis
plusieurs applis, sans avoir à reconfigurer la sortie de ces applis.
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
À une époque, on pouvait faire des bidouilles avec LD_PRELOAD avec esd (enlightenment sound daemon), voir le script esddsp.
Ça remonte à vieux, ESD fait peut-etre des trucs plus cleans depuis.
-- Stéphane
Remi Moyen
On Thu, 9 Oct 2003, Stephane CHAZELAS wrote:
À une époque, on pouvait faire des bidouilles avec LD_PRELOAD avec esd (enlightenment sound daemon), voir le script esddsp.
Ça remonte à vieux, ESD fait peut-etre des trucs plus cleans depuis.
Moui moui... Oui, en effet ! ESD comme ARTS font simplement une bidouille avec LD_PRELOAD avant de lancer l'application.
J'ai testé sur une machine où ARTS est installé, si LD_PRELOAD=/usr/lib/libartsdsp.so.0:/usr/lib/libartsc.so.0:/lib/libdl.so.2, on peut ensuite lancer les applis sans problème, elles passent directement par ARTS. Cool !
Je suppose que le fonctionnement est le même avec ESD. Oui, après test, c'est tout pareil (avec libesddsp.so.0 et libesd.so.0).
Par hasard, tu aurais une explication de pourquoi ça marche ?
Par contre, il semblerait que ESD comme ARTS introduisent un léger décalage entre le moment où un son est envoyé au serveur, et le moment où il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ; dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur stop -- et ça n'arrive pas quand je désactive tous les serveurs de son pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution ?
J'ai déjà posé la question plusieurs fois, sans succès, mais bon, peut-être qu'aujourd'hui sera la bonne... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Thu, 9 Oct 2003, Stephane CHAZELAS wrote:
À une époque, on pouvait faire des bidouilles avec LD_PRELOAD
avec esd (enlightenment sound daemon), voir le script esddsp.
Ça remonte à vieux, ESD fait peut-etre des trucs plus cleans
depuis.
Moui moui... Oui, en effet ! ESD comme ARTS font simplement une bidouille
avec LD_PRELOAD avant de lancer l'application.
J'ai testé sur une machine où ARTS est installé, si
LD_PRELOAD=/usr/lib/libartsdsp.so.0:/usr/lib/libartsc.so.0:/lib/libdl.so.2,
on peut ensuite lancer les applis sans problème, elles passent directement
par ARTS. Cool !
Je suppose que le fonctionnement est le même avec ESD. Oui, après test,
c'est tout pareil (avec libesddsp.so.0 et libesd.so.0).
Par hasard, tu aurais une explication de pourquoi ça marche ?
Par contre, il semblerait que ESD comme ARTS introduisent un léger
décalage entre le moment où un son est envoyé au serveur, et le moment où
il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ;
dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur
stop -- et ça n'arrive pas quand je désactive tous les serveurs de son
pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution
?
J'ai déjà posé la question plusieurs fois, sans succès, mais bon,
peut-être qu'aujourd'hui sera la bonne...
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
À une époque, on pouvait faire des bidouilles avec LD_PRELOAD avec esd (enlightenment sound daemon), voir le script esddsp.
Ça remonte à vieux, ESD fait peut-etre des trucs plus cleans depuis.
Moui moui... Oui, en effet ! ESD comme ARTS font simplement une bidouille avec LD_PRELOAD avant de lancer l'application.
J'ai testé sur une machine où ARTS est installé, si LD_PRELOAD=/usr/lib/libartsdsp.so.0:/usr/lib/libartsc.so.0:/lib/libdl.so.2, on peut ensuite lancer les applis sans problème, elles passent directement par ARTS. Cool !
Je suppose que le fonctionnement est le même avec ESD. Oui, après test, c'est tout pareil (avec libesddsp.so.0 et libesd.so.0).
Par hasard, tu aurais une explication de pourquoi ça marche ?
Par contre, il semblerait que ESD comme ARTS introduisent un léger décalage entre le moment où un son est envoyé au serveur, et le moment où il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ; dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur stop -- et ça n'arrive pas quand je désactive tous les serveurs de son pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution ?
J'ai déjà posé la question plusieurs fois, sans succès, mais bon, peut-être qu'aujourd'hui sera la bonne... -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Thomas Nemeth
Le jeu 09 oct 2003 à 14:20, Remi Moyen a tapoté : | | Par contre, il semblerait que ESD comme ARTS introduisent un léger | décalage entre le moment où un son est envoyé au serveur, et le moment où | il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ; | dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur | stop -- et ça n'arrive pas quand je désactive tous les serveurs de son | pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution | ?
C'est bien simple : les streams sont bufferisés et leur lecture (par arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de temps après l'arrêt de l'émission par l'appli qui produit le son (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2 secondes de données...
Thomas -- MB un troll ? Meuh non ! Un vrai troll est imprévisible :-) -+- LD in: Guide du Cabaliste Usenet - Contrôle de routine -+-
Le jeu 09 oct 2003 à 14:20, Remi Moyen a tapoté :
|
| Par contre, il semblerait que ESD comme ARTS introduisent un léger
| décalage entre le moment où un son est envoyé au serveur, et le moment où
| il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ;
| dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur
| stop -- et ça n'arrive pas quand je désactive tous les serveurs de son
| pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution
| ?
C'est bien simple : les streams sont bufferisés et leur lecture (par
arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de
temps après l'arrêt de l'émission par l'appli qui produit le son
(xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2
secondes de données...
Thomas
--
MB un troll ? Meuh non ! Un vrai troll est imprévisible :-)
-+- LD in: Guide du Cabaliste Usenet - Contrôle de routine -+-
Le jeu 09 oct 2003 à 14:20, Remi Moyen a tapoté : | | Par contre, il semblerait que ESD comme ARTS introduisent un léger | décalage entre le moment où un son est envoyé au serveur, et le moment où | il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ; | dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur | stop -- et ça n'arrive pas quand je désactive tous les serveurs de son | pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution | ?
C'est bien simple : les streams sont bufferisés et leur lecture (par arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de temps après l'arrêt de l'émission par l'appli qui produit le son (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2 secondes de données...
Thomas -- MB un troll ? Meuh non ! Un vrai troll est imprévisible :-) -+- LD in: Guide du Cabaliste Usenet - Contrôle de routine -+-
Remi Moyen
On Thu, 9 Oct 2003, Thomas Nemeth wrote:
| Par contre, il semblerait que ESD comme ARTS introduisent un léger | décalage entre le moment où un son est envoyé au serveur, et le moment où | il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ; | dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur | stop -- et ça n'arrive pas quand je désactive tous les serveurs de son | pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution | ?
C'est bien simple : les streams sont bufferisés et leur lecture (par arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de temps après l'arrêt de l'émission par l'appli qui produit le son (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2 secondes de données...
Ah, oui, et je suppose que c'est la même chose qui produit le décalage au démarrage, le son n'étant envoyé à la carte son que quand le buffer est plein.
Est-ce que ça veut dire que si je réduis drastiquement la taille du buffer, ce décalage disparaitra ? Et y'aura-t-il d'autres inconvénients (un son plus vulnérable aux erreurs ou ralentissements, je suppose, mais à part ça ? ) ?
Dernière question : où sont stockés les paramètres par défaut d'ARTS ??? J'ai cherché dans tout /etc, et je n'y rien vu de relatif à artsd.
Merci ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
On Thu, 9 Oct 2003, Thomas Nemeth wrote:
| Par contre, il semblerait que ESD comme ARTS introduisent un léger
| décalage entre le moment où un son est envoyé au serveur, et le moment où
| il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ;
| dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur
| stop -- et ça n'arrive pas quand je désactive tous les serveurs de son
| pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution
| ?
C'est bien simple : les streams sont bufferisés et leur lecture (par
arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de
temps après l'arrêt de l'émission par l'appli qui produit le son
(xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2
secondes de données...
Ah, oui, et je suppose que c'est la même chose qui produit le décalage au
démarrage, le son n'étant envoyé à la carte son que quand le buffer est
plein.
Est-ce que ça veut dire que si je réduis drastiquement la taille du
buffer, ce décalage disparaitra ? Et y'aura-t-il d'autres inconvénients
(un son plus vulnérable aux erreurs ou ralentissements, je suppose, mais à
part ça ? ) ?
Dernière question : où sont stockés les paramètres par défaut d'ARTS ???
J'ai cherché dans tout /etc, et je n'y rien vu de relatif à artsd.
Merci !
--
Rémi Moyen
"Malgré les apparences, le temps est très varié à Nancy :
pluie, nuages, neige, brouillard, grêle, ..."
| Par contre, il semblerait que ESD comme ARTS introduisent un léger | décalage entre le moment où un son est envoyé au serveur, et le moment où | il est joué (par exemple, sur une vidéo, le son et l'image sont décalés ; | dans xmms, le son continue une seconde ou deux après que j'ai cliqué sur | stop -- et ça n'arrive pas quand je désactive tous les serveurs de son | pour passer directement à /dev/dsp). Est-ce normal ? Y'a-t-il une solution | ?
C'est bien simple : les streams sont bufferisés et leur lecture (par arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de temps après l'arrêt de l'émission par l'appli qui produit le son (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2 secondes de données...
Ah, oui, et je suppose que c'est la même chose qui produit le décalage au démarrage, le son n'étant envoyé à la carte son que quand le buffer est plein.
Est-ce que ça veut dire que si je réduis drastiquement la taille du buffer, ce décalage disparaitra ? Et y'aura-t-il d'autres inconvénients (un son plus vulnérable aux erreurs ou ralentissements, je suppose, mais à part ça ? ) ?
Dernière question : où sont stockés les paramètres par défaut d'ARTS ??? J'ai cherché dans tout /etc, et je n'y rien vu de relatif à artsd.
Merci ! -- Rémi Moyen "Malgré les apparences, le temps est très varié à Nancy : pluie, nuages, neige, brouillard, grêle, ..."
Thomas Nemeth
Le jeu 09 oct 2003 à 14:55, Remi Moyen a tapoté : | On Thu, 9 Oct 2003, Thomas Nemeth wrote: | | > C'est bien simple : les streams sont bufferisés et leur lecture (par | > arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de | > temps après l'arrêt de l'émission par l'appli qui produit le son | > (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2 | > secondes de données... | | Ah, oui, et je suppose que c'est la même chose qui produit le décalage au | démarrage, le son n'étant envoyé à la carte son que quand le buffer est | plein.
Vala.
| Est-ce que ça veut dire que si je réduis drastiquement la taille du | buffer, ce décalage disparaitra ?
Normalement.
| Et y'aura-t-il d'autres inconvénients | (un son plus vulnérable aux erreurs ou ralentissements, je suppose, mais à | part ça ? ) ?
Je pense que le buffer sert aussi au mixage avec les sons venant d'autres applications (xmms + "sons système" de KDE + cequetuveux). Donc si la taille n'est pas suffisante pour assurer un flux pendant que le mixage se fait sur le reste, il est possible que ça sorte en haché (ÀMHA).
| Dernière question : où sont stockés les paramètres par défaut d'ARTS ??? | J'ai cherché dans tout /etc, et je n'y rien vu de relatif à artsd.
Je ne sais pas : je n'utilise ni KDE ni Gnome.
| Merci !
Avec plaisir.
Thomas -- Aurais-je manque une loi permettant a n'iumporte que CON (excusez moi, mais je vois pas d'autre terme) à salir et à insulter les marques des sociétés connues ? -+- JD-P in NPC : Dura lex basta crapoto, et que ça saute ! -+-
Le jeu 09 oct 2003 à 14:55, Remi Moyen a tapoté :
| On Thu, 9 Oct 2003, Thomas Nemeth wrote:
|
| > C'est bien simple : les streams sont bufferisés et leur lecture (par
| > arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de
| > temps après l'arrêt de l'émission par l'appli qui produit le son
| > (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2
| > secondes de données...
|
| Ah, oui, et je suppose que c'est la même chose qui produit le décalage au
| démarrage, le son n'étant envoyé à la carte son que quand le buffer est
| plein.
Vala.
| Est-ce que ça veut dire que si je réduis drastiquement la taille du
| buffer, ce décalage disparaitra ?
Normalement.
| Et y'aura-t-il d'autres inconvénients
| (un son plus vulnérable aux erreurs ou ralentissements, je suppose, mais à
| part ça ? ) ?
Je pense que le buffer sert aussi au mixage avec les sons venant
d'autres applications (xmms + "sons système" de KDE + cequetuveux).
Donc si la taille n'est pas suffisante pour assurer un flux pendant
que le mixage se fait sur le reste, il est possible que ça sorte en
haché (ÀMHA).
| Dernière question : où sont stockés les paramètres par défaut d'ARTS ???
| J'ai cherché dans tout /etc, et je n'y rien vu de relatif à artsd.
Je ne sais pas : je n'utilise ni KDE ni Gnome.
| Merci !
Avec plaisir.
Thomas
--
Aurais-je manque une loi permettant a n'iumporte que CON (excusez moi,
mais je vois pas d'autre terme) à salir et à insulter les marques des
sociétés connues ?
-+- JD-P in NPC : Dura lex basta crapoto, et que ça saute ! -+-
Le jeu 09 oct 2003 à 14:55, Remi Moyen a tapoté : | On Thu, 9 Oct 2003, Thomas Nemeth wrote: | | > C'est bien simple : les streams sont bufferisés et leur lecture (par | > arts ou esd) s'arrête quand le buffer est vide, ce qui arrive peu de | > temps après l'arrêt de l'émission par l'appli qui produit le son | > (xmms ou autre). Le temps de vider le buffer qui doit contenir 1 à 2 | > secondes de données... | | Ah, oui, et je suppose que c'est la même chose qui produit le décalage au | démarrage, le son n'étant envoyé à la carte son que quand le buffer est | plein.
Vala.
| Est-ce que ça veut dire que si je réduis drastiquement la taille du | buffer, ce décalage disparaitra ?
Normalement.
| Et y'aura-t-il d'autres inconvénients | (un son plus vulnérable aux erreurs ou ralentissements, je suppose, mais à | part ça ? ) ?
Je pense que le buffer sert aussi au mixage avec les sons venant d'autres applications (xmms + "sons système" de KDE + cequetuveux). Donc si la taille n'est pas suffisante pour assurer un flux pendant que le mixage se fait sur le reste, il est possible que ça sorte en haché (ÀMHA).
| Dernière question : où sont stockés les paramètres par défaut d'ARTS ??? | J'ai cherché dans tout /etc, et je n'y rien vu de relatif à artsd.
Je ne sais pas : je n'utilise ni KDE ni Gnome.
| Merci !
Avec plaisir.
Thomas -- Aurais-je manque une loi permettant a n'iumporte que CON (excusez moi, mais je vois pas d'autre terme) à salir et à insulter les marques des sociétés connues ? -+- JD-P in NPC : Dura lex basta crapoto, et que ça saute ! -+-
