Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Solucionando algunos problemas de drivers

dodger's Diary
Por dodger
departamento cosas a las que me dediqué en la euskal , Sección Diarios
Puesto a las Thu Jul 31st, 2003 at 01:34:03 PM CET
A la euskal party me llevé, por supuesto, el portatil. Y, como tuve tiempo, estuve solucionando un par de problemas que tenía: algunos fallos en el sonido, y la aceleración 3D. Como unos links siempre son útiles, comentaré un poco los problemas que tuve, y como los solucioné.

 


Primero, el sonido. Tenía los módulos del kernel para OSS, y para las tarjetas integradas de intel. Y me hacían cosas raras: para empezar, tenía que cargarlos en un orden adecuado: ac97_codec soundcore sound i810_audio. Cada vez que arrancaba. No valía con ponerlos en /etc/modules, no pregunteis por qué. Además, había cosas que no iban bien. Por ejemplo, el control del volumen del XMMS no funcionaba.
Un colega me habó de Advanced Linux Sound Architecture (ALSA). Y una maravilla, oye. Ya carga todo solito, el control de volumen funciona, y todo es tan estupendo como en los anuncios de compresas :)

Segundo problema: Aceleración 3D. Mi portatil tiene una radeon9000. El módulo del kernel para radeon funciona para las X, pero no me da aceleración 3D. A si que, de nuevo, un proyecto chulo: DRI - Direct Rendering Infrastructure . Se dedican precisamente a esto :)
Sin embargo, su CVS iba fatal (estuve como hora y media tratando de bajarme las fuentes). Pero, como debian es debian, y existe ese maravilloso apt, las cosas mejoraron: hay una página con fuentes no oficiales para el apt muy maja, que me dió un sitio donde están los paquetes de dri: (creo que era "deb http://marillat.free.fr/ unstable main", pero no estoy seguro, no tengo aquí el portatil para comprobarlo). Una vez con las fuentes instaladas, se compilan los módulos, se situa el radeon.o en un lugar adecuado de /lib/modules, se quita el módulo de radeon del kernel, y se pone en el fichero de configuración de las X el nuevo módulo. Y ¡tachán!, ya puedo jugar al quake bajo linux :)
Como nota anecdótica: Si está activado el sonido en las kde (para que suene al arrancar, al apagar, y tal), el quake tarda mogollón al arrancar (debe haber algún tipo de conflicto). A si que conviene desactivarlo en el kpanel de control ;)

--
dodger
www.seastorm.org
< Linux y la "mala memoria" (29 comments) | Liberado FacturaLUX v0.7(Prototipo) (22 comments) >
Enlaces Relacionados
· Advanced Linux Sound Architecture (ALSA)
· DRI - Direct Rendering Infrastructure
· página con fuentes no oficiales para el apt
· www.seastorm.org
· More on dodger's Diary
· Also by dodger

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Solucionando algunos problemas de drivers | 5 comentarios (5 temáticos, editoriales, 0 ocultos)
Lo del sonido y el Quake (none / 0) (#1)
por Ed hunter (eduardo.mestreENhispalinux.es) a las Thu Jul 31st, 2003 at 02:09:20 PM CET
(Información Usuario) http://speedball.servemp3.com

En principio no debería haber problemas, ya que precisamente ALSA hace drivers no apropiativos, es decir, los programas no se apropian del dispositivo permitiendo que varios programas accedan a la tarjeta de sonido a la vez. Pero aún así, tanto KDE como GNOME tienen un daemon que es el encargado de reproducir los ruiditos de las aplicaciones de dichos escritorios y es quién se apodera de la tarjeta de sonido.

En GNOME el daemon es esound, que incluye ciertas utilidades, entre ellas un wrapper (esddsp) y un programa de control (esdctl) que permite parar y arrancar el esound. En tal caso, según programas, ejecutando esddsp programa se integraría el sonido con los eventos del GNOME, a cambio de perder rendimiento. En el caso del Quake yo hago lo siguiente: esdctl stop ; quake ; esdctl start.

En KDE el daemon es el aRts, el wrapper es el artsdsp, y la herramienta de control es artsshell.

Algunas distribuciones utilizan el soundwrapper, que es un simple script que según se ejecute aRts o esound llama a uno u otro programa, y si no hay nada, arranca el programa tal cual.

Es una lástima que KDE y GNOME no utilicen los dos el mismo daemon mezclador de sonido, aunque tal vez en un futuro lleguen a hacerlo.

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


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:

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