Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Solucionando algunos problemas de drivers | 5 comentarios (5 temáticos, editoriales, 0 ocultos)
Creo que no (none / 0) (#2)
por jorginius ("jorginius" en Google Mail) a las Thu Jul 31st, 2003 at 05:22:26 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

En principio no debería haber problemas, ya que precisamente ALSA hace drivers no apropiativos [...] los programas no se apropian del dispositivo permitiendo que varios programas accedan a la tarjeta de sonido a la vez.

Lo que vi que hacía ALSA hace un par de años es dar soporte para la mezcla de fuentes distintas de sonido por hardware, si la tarjeta internamente es capaz de hacerlo.

¿No estarás confundiendo eso de "no apropiativo" con que la biblioteca sea reentrante?.

Si tú tarjeta es mala, ALSA no te evitará la necesidad de usar un mezclador por software (bueno, a menos que ALSA haya cambiado en esodesde que lo estuve mirando). No es un ventaja de ALSA, que no emula la mezcla si la tarjeta no lo soporta, es más bien una "feature hardware" que el driver debe contemplar. Hay drivers OSS que la soportan.

¿Por qué, si la tarjeta no lo incluye, el driver no lo simula?. Ese es el esquema que usa DirectSound en Windows pero parece que no convence a nadie. Mientras tanto tenemos los mezclador software en espacio de usuario, ESounD y aRts.

En tal caso, según programas, ejecutando esddsp programa se integraría el sonido con los eventos del GNOME, a cambio de perder rendimiento.

Lo del rendimiento es lo de menos. Hay al menos dos problemas a parte de ese. Primero que si el programa que quieres lanzar pretende hacer un mmap() del dispositivo (Como quake y otros), el chisme no funciona. Segundo que si el binario es setsuid o lo lanzamos como root tampoco funcionará, puesto que el truco del esddsp consiste en interponerse entre el programa y /dev/dsp vía LD_PRELOAD, capturando el acceso al dispositivo, y por motivos de seguridad root no hace caso de LD_PRELOAD.

Es una lástima que KDE y GNOME no utilicen los dos el mismo daemon mezclador de sonido

ALSA debería incluir algo de esto, un mezclador para todos los drivers (simulado o no). La verdad es que no entiendo muy bien por qué no se hace así, como en Windows, vaya. Todo el mundo dice "es una aberración", pero no le veo las desventajas, por lo menos comparado con lo que tenemos ahora.

De esta forma, no haría falta ningún demonio mezclador ni para GNOME ni para KDE.

[ Padre ]


Gnome usará Arts, creo (none / 0) (#3)
por musg0 a las Thu Jul 31st, 2003 at 10:14:49 PM CET
(Información Usuario) http://helvete.escomposlinux.org

No sé donde leí que Gnome en la siguiente versión usará aRts en vez de ESD. También existe una versión diferente y compatible de ESD llamada ASD.

Yo también estoy contigo en que el demonio de sonido debería ser parte de alsa y ser transparente para el usuario. Al fin y al cabo es algo que debería ser parte del hardware, y si no lo tiene, debería ser emulado por el driver.

En la guadec del 2001 parece que hablaron algo de implementar aRts en Gnome

[ Padre ]


¿aRts en GNOME? parece que no (none / 0) (#4)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Fri Aug 1st, 2003 at 12:36:01 AM CET
(Información Usuario) http://speedball.servemp3.com

Según tengo entendido, se hablo largo y tendido para substituir el esound por aRts incluso para GNOME 2.0 debido a las limitaciones de esound. Desgraciadamente (por el hecho de que habría mayor integración entre escritorios según mi opinión), decidieron no llevarlo a cabo, ya que la mayor parte de las limitaciones de esound, según ellos, se mantenían en aRts, aunque consideraban que este último es superior.

Así que la idea es mantener esound por razones de compatibilidad mientras no tubiesen algo que superase todas las limitaciones de esound. Lo que ignoro es si en realidad alguien se ha puesto a trabajar en ello.

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


 
Por alusiones puntualizo (none / 0) (#5)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Fri Aug 1st, 2003 at 12:55:35 AM CET
(Información Usuario) http://speedball.servemp3.com

¿No estarás confundiendo eso de "no apropiativo" con que la biblioteca sea reentrante?.

En principio no, no creo haber confundido eso, simplemente recuerdo haber leido algo así "consistent support for multiple instances of the same card", y como no decía nada de "if the hardware supports" simplemente pensé que si usas ALSA tienes un método consistente para tener múltiples instancias soble la misma tarjeta... en fin, así de burro soy. Lo que si podía entender es que sólo lo soportase usando la API ALSA y no con la emulación OSS, pero si además se exige que el harware lo soporte es algo que ignoro.

hacer un mmap() del dispositivo (Como quake y otros), el chisme no funciona...

No quería exponer todas las limitaciones de los wrappers de sonido. Es cierto, Quake no acepta usar wrapper (por eso recomiendo resactivar el daemon), pero hay muchos otros programas que si funcionan, muchos juegos entre ellos, pero que por mi experiencia, el rendimiento decae tanto que siempre es mejor desactivar el daemon en todos los juegos. Recordemos que no sólo del Quake vive el jugador ;).

Una ventaja de usar un daemon en lugar de directamente el driver es poder enmascarar dispositivos remotos. Por ejemplo gracias a los daemons podemos hacer que, de forma transparente para la aplicación, el sonido suene en una máquina diferente a la que se ejecuta el programa. De hecho creo recordar que esa era una de las limitaciones que compartían el esound y el aRts y que no convencía a la gente de GNOME. No digo que no se pueda hacer (se puede, perfectamente, tener el xmms ejecutandose en una máquina y que el sonido salga por otra) pero no es algo transparente, o tan transparente como exportar el $DISPLAY

Speedball la banda de heavy más chunga
Ven al Helvete Metal Bar
[ Padre ]


 

Solucionando algunos problemas de drivers | 5 comentarios (5 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda