existe-t-il un moyen plus propre qu'un serveur son (esound, artds...)
pour mixer plusieurs sources audio sous NetBSD ?
Tout ce que j'ai trouvé c'est vchans pour FreeBSD. Mais vu que le code
audio est très différent entre les deux systèmes je pense que c'est
pas réaliste de vouloir leur piquer leur code.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
espie
In article <421781ae$0$14333$, Cyrille Szymanski wrote:
Bonjour,
existe-t-il un moyen plus propre qu'un serveur son (esound, artds...) pour mixer plusieurs sources audio sous NetBSD ?
Oui, reecrire le pilote son pour le faire evoluer vers quelque chose de vaguement plus recent.
Les pilotes son de NetBSD (et d'OpenBSD) aussi sont passablement a la traine cote capacite de mixage et autres joyeusetes. Faut dire aussi que l'interface n'incite pas a la joie, pas simple de modifier la partie hw independante sans toucher au reste.
Bref, a l'epoque ou ma machine principale avait une maestroII, j'envisageais assez serieusement de rendre /dev/audio plusieurs fois ouvrable. Maintenant que quasiment tout le monde a des AC'97 stereo, ca serait plus simple (notoirement) de rajouter un mixage en soft. Les difficultes: - le resampling en cas d'ouvertures a frequences differentes - le controle du volume. - les applis temps reel coexistant avec le reste.
Le deuxieme point est passablement complexe. On ne peut pas trop se permettre de passer brutalement d'un jeu de valeurs a un jeu de valeurs deux fois plus petites lorsqu'on mixe de 1 a 2 canaux (meme si l'acoustique fait que la perte est logarithmique), sans compter qu'on va avoir rapidement du bruit si on mixe trop et qu'on fait pas gaffe a recuperer plus ou moins les erreurs d'echantillonmage.
Le troisieme point est drole aussi: les applis temps reel vont remplir leur tampon et se baser dessus pour synchroniser le son et autre chose, les autres applis vont jouer du son quand elles veulent... bref, si une appli a le son ouvert et n'envoie rien, c'est pas grave: ca bloque. Si deux applis ont le son ouvert, que l'une joue des trucs et l'autre rien, on fait quoi ? On peut pas trop attendre apres la deuxieme... sauf que si une appli pedale un peu lentement, peut-etre qu'elle est aussi temps reel, mais vaguement a la traine. Bref, c'est joyeux.
Les jolis serveurs userland a la arts, esd and co occultent joyeusement ce dernier probleme: pas la peine de vouloir faire du temps reel avec, on se coltine au moins dix a quinze millisecondes d'ecart entre l'audio et le graphique...
In article <421781ae$0$14333$626a14ce@news.free.fr>,
Cyrille Szymanski <cns@cns2.invalid> wrote:
Bonjour,
existe-t-il un moyen plus propre qu'un serveur son (esound, artds...)
pour mixer plusieurs sources audio sous NetBSD ?
Oui, reecrire le pilote son pour le faire evoluer vers quelque chose
de vaguement plus recent.
Les pilotes son de NetBSD (et d'OpenBSD) aussi sont passablement a la
traine cote capacite de mixage et autres joyeusetes. Faut dire aussi que
l'interface n'incite pas a la joie, pas simple de modifier la partie hw
independante sans toucher au reste.
Bref, a l'epoque ou ma machine principale avait une maestroII, j'envisageais
assez serieusement de rendre /dev/audio plusieurs fois ouvrable. Maintenant
que quasiment tout le monde a des AC'97 stereo, ca serait plus simple
(notoirement) de rajouter un mixage en soft. Les difficultes:
- le resampling en cas d'ouvertures a frequences differentes
- le controle du volume.
- les applis temps reel coexistant avec le reste.
Le deuxieme point est passablement complexe. On ne peut pas trop se permettre
de passer brutalement d'un jeu de valeurs a un jeu de valeurs deux fois plus
petites lorsqu'on mixe de 1 a 2 canaux (meme si l'acoustique fait que la
perte est logarithmique), sans compter qu'on va avoir rapidement du bruit
si on mixe trop et qu'on fait pas gaffe a recuperer plus ou moins les
erreurs d'echantillonmage.
Le troisieme point est drole aussi: les applis temps reel vont remplir leur
tampon et se baser dessus pour synchroniser le son et autre chose, les autres
applis vont jouer du son quand elles veulent... bref, si une appli a le son
ouvert et n'envoie rien, c'est pas grave: ca bloque. Si deux applis ont le
son ouvert, que l'une joue des trucs et l'autre rien, on fait quoi ?
On peut pas trop attendre apres la deuxieme... sauf que si une appli pedale
un peu lentement, peut-etre qu'elle est aussi temps reel, mais vaguement a
la traine. Bref, c'est joyeux.
Les jolis serveurs userland a la arts, esd and co occultent joyeusement ce
dernier probleme: pas la peine de vouloir faire du temps reel avec, on
se coltine au moins dix a quinze millisecondes d'ecart entre l'audio et le
graphique...
In article <421781ae$0$14333$, Cyrille Szymanski wrote:
Bonjour,
existe-t-il un moyen plus propre qu'un serveur son (esound, artds...) pour mixer plusieurs sources audio sous NetBSD ?
Oui, reecrire le pilote son pour le faire evoluer vers quelque chose de vaguement plus recent.
Les pilotes son de NetBSD (et d'OpenBSD) aussi sont passablement a la traine cote capacite de mixage et autres joyeusetes. Faut dire aussi que l'interface n'incite pas a la joie, pas simple de modifier la partie hw independante sans toucher au reste.
Bref, a l'epoque ou ma machine principale avait une maestroII, j'envisageais assez serieusement de rendre /dev/audio plusieurs fois ouvrable. Maintenant que quasiment tout le monde a des AC'97 stereo, ca serait plus simple (notoirement) de rajouter un mixage en soft. Les difficultes: - le resampling en cas d'ouvertures a frequences differentes - le controle du volume. - les applis temps reel coexistant avec le reste.
Le deuxieme point est passablement complexe. On ne peut pas trop se permettre de passer brutalement d'un jeu de valeurs a un jeu de valeurs deux fois plus petites lorsqu'on mixe de 1 a 2 canaux (meme si l'acoustique fait que la perte est logarithmique), sans compter qu'on va avoir rapidement du bruit si on mixe trop et qu'on fait pas gaffe a recuperer plus ou moins les erreurs d'echantillonmage.
Le troisieme point est drole aussi: les applis temps reel vont remplir leur tampon et se baser dessus pour synchroniser le son et autre chose, les autres applis vont jouer du son quand elles veulent... bref, si une appli a le son ouvert et n'envoie rien, c'est pas grave: ca bloque. Si deux applis ont le son ouvert, que l'une joue des trucs et l'autre rien, on fait quoi ? On peut pas trop attendre apres la deuxieme... sauf que si une appli pedale un peu lentement, peut-etre qu'elle est aussi temps reel, mais vaguement a la traine. Bref, c'est joyeux.
Les jolis serveurs userland a la arts, esd and co occultent joyeusement ce dernier probleme: pas la peine de vouloir faire du temps reel avec, on se coltine au moins dix a quinze millisecondes d'ecart entre l'audio et le graphique...
