Sonido rt en debian y más preguntas : GNU/Linux

Hola, en un AMD Athlon k7, he instalado debian etch (testing). El nucleo versión:

Alguien escribió:
$ uname -r
2.6.18-3-k7

Tengo dos preguntas:
- ¿Debo elegir este núcleo específico para k7 o instalar otro?
- ¿Cómo activar el tiempo real?. En esta versión de núcleo hacen falta parches?. En los repositorios está un módulo llamado realtime-lsm.

Pensaba que activando los repositorios de http://www.debian-multimedia.org/ dispondría de nucleos para tiempo real precompilados.

Gracias

Robakun escribió:
- ¿Debo elegir este núcleo específico para k7 o instalar otro?

Para mi que ese está bien , aunque quizá podrías usar 2.6.18-3-486
también , ese es el que tengo yo en un amd64 , aparte del que le tomé
prestado a 64studio (i386)

Alguien escribió:
- ¿Cómo activar el tiempo real?. En esta versión de núcleo hacen
falta parches?. En los repositorios está un módulo llamado
realtime-lsm.

Prueba a poner esto en /etc/security/limits.conf



@audio            -      rtprio          99

@audio            -       nice          -10

@audio            -      memlock         4000000

Comprueba que tu usario está en el grupo audio y reinicia tu sesión.

A ver qué resultado te da. Esa ,según tengo entendido, es la manera
aceptada por los desarrolladores del kernel para dar prioridad de tiempo
real a los procesos que lo necesiten sin comprometer demasiado la
seguridad del sistema.

En cuanto a lo de los parches está claro que si le metes el de Ingo
Molnar a un "vanilla" vas a obtener mucho mejor rendimiento que con ese
"a pelo".

Ese realtime-lsm , por la descripción que da apt, más que un módulo es
un script para gestionar la carga y descarga del módulo , que habría que
compilar, creo .
He probado a compilarlo con module-assistant , y el mensaje de error
que lanza es que realtime-ls-module no funcionará con el kernel
2.6.18-3. Esto lo probé con las headers , me da que habrá que recompilar
el kernel para ello.Sin embargo yo compilé un 2.6.18 vanilla con el parche de Ingo y el realtime-lsm pero me da un error al cargarlo que no sé como resolver.
El comando para cargarlo sería



# modprobe realtime gid=29

lo de gid=29 sería para darle prioridad a los procesos lanzados por ese grupo , que en debian es audio, el error que me da es :



realtime: Unknown parameter `gid'

Si lo cargo sin ese parámetro si que va, pero me da que no es muy recomendable.

Aunque he de decir que usando la confguración que puse arriba en /etc/security/limits.conf esto va como un tiro sin necesidad de usar ese módulo.

http://www.debian-multimedia.org/ creo que sustituye al antiguo
repositorio de Christian Marillat , en el que se encontraban los códecs
non-free , además de otros programaas de la misma calaña.

Vale , ya me callo. A ver si eso te vale.

Saludos.

"guitman @ 20 Ene 2007 - 07:20 PM" escribió:

Prueba a poner esto en /etc/security/limits.conf



@audio            -      rtprio          99

@audio            -       nice          -10

@audio            -      memlock         4000000

Comprueba que tu usario está en el grupo audio y reinicia tu sesión.

Gracias!, lo que he probado funciona muy bien. 0(0) xruns al cabo de un rato usando rosegarden, era algo que no esperaba. Dentro de las posiblidades del equipo va muy fluido.

Gracias guitman

Robakun @ 20 Ene 2007 - 05:25 PM escribió:

- ¿Debo elegir este núcleo específico para k7 o instalar otro?

Con la configuración en limits.conf que te pasan te irá bien, pero yo he compilado esta semana uno con los parches preempt de Ingo Molnar para k7. Claro que son unos cuantos megas, ¿cómo se te ocurre que te lo podría pasar?

"guitman @ 20 Ene 2007 - 07:20 PM" escribió:

El comando para cargarlo sería



# modprobe realtime gid=29

lo de gid=29 sería para darle prioridad a los procesos lanzados por ese grupo , que en debian es audio, el error que me da es :



realtime: Unknown parameter `gid'

Si lo cargo sin ese parámetro si que va, pero me da que no es muy recomendable.

Aunque he de decir que usando la confguración que puse arriba en /etc/security/limits.conf esto va como un tiro sin necesidad de usar ese módulo.

En 64studio hay un archivo /etc/default/realtime con este contenido:



# Configuration file for the realtime LSM module

# PARAMETERS can be one or more of:

#

# gid=xx      (allow realtime capabilities for gid xx only)

# any=1|0     (allow any user and process to have realtime)

# mlock=1|0   (allow/disallow mlocking)

# allcaps=1|0 (allow setpcap functionality (dangerous!))



# enable loading of module at startup

ENABLE=yes



# parameter settings for module

PARAMETERS="gid=29"

Mira a ver si lo tienes en tu distro y si no créalo a ver si funciona

En cuanto a lo de limits.conf no se del tema de realtime pero parece que ese archivo es para establecer los límites de uso de ciertas funciones. Por tanto a no ser que sea para no pasarse de la raya en las concesiones de prioridad de tiempo real, no veo como puede ser que mejore el rendimiento...

:

A ver, por tenerlo todo claro.

En este momento ya no es necesario utilizar módulos del tipo realtime-lsm para que las aplicaciones tengan acceso al "tiempo real". Para esto es necesario que la versión actual de libpam-modules sea igual o superior a la 0.79-4. Si usas Debian sid ya tienes esta versión instalada. Si usas una versión antigua de Debian o Ubuntu compruébalo con:

$ dpkg -s libpam-modules

¿Tienes una versión anterior? Entonces bájate un paquete libpam-modules parcheado de aquí:

http://burkhard.seite9.de/pam_debian_rlimits/

e instálalo con:

# dpkg -i libpam-modules_0.79-4_i386.deb

Ahora puedes decidir qué aplicaciones pueden acceder al "tiempo real". Esto lo haces añadiendo estas líneas a /etc/security/limits.conf:

@audio - rtprio 99
@audio - nice -10
@audio - memlock 4000000

Esto quiere decir que cualquier aplicación arrancada por cualquier usuario en el grupo "audio" (y el usuario por defecto de tu Debian/Ubuntu está en el grupo) puede acceder al tiempo real, ponerse a sí misma con una prioridad mayor y bloquear memoria.

¿Mejora esto el rendimiento del audio? Sí, porque ahora cualquier usuario en el grupo audio puede arrancar jack con la opcion -R. Así jack mejora mucho su latencia y la estabilidad del sistema. En particular jack bloquea en la memoria cualquier aplicación enganchada a jack con lo que el sistema no hará swap con ella.

Ojo, con el libpam-modules que indico realtime-lsm no es necesario y es mejor que no se cargue el módulo.

Además de lo explicado, mejora aún más el rendimiento añadir al kernel los parches de Ingo Molnar para un nucleo apropiativo "preemptive". Así las aplicaciones de audio nunca se dejarán quitar tiempo de CPU por los servicios en segundo plano. Yo generalmente me lo compilo yo mismo desde un kernel "vanilla" bajado de kernel.org. Los parches están aquí:

http://people.redhat.com/mingo/realtime-preempt/

Mira que parche está. Por ejemplo ahora está:

patch-2.6.20-rc5-rt7

Lo que quiere decir que te bajes el kernel 2.6.20, apliques el parche y compiles, el resultado será un kernel "multimedia".

Estas instrucciones están en inglés pero son válidas para Debian y Ubuntu.

https://help.ubuntu.com/community/HowTo ... Preemption

Y si quieres más sobre el tema, sígueme en del.icio.us:

http://del.icio.us/ivalladt/realtime

¡Acabo de encontrar que te puedes bajar un kernel multimedia para x64 o 32 bits aquí!

http://archive.64studio.com/pool/main/l/linux-2.6/

"malkavian" escribió:

En 64studio hay un archivo /etc/default/realtime con este contenido:



# Configuration file for the realtime LSM module

# PARAMETERS can be one or more of:

#

# gid=xx      (allow realtime capabilities for gid xx only)

# any=1|0     (allow any user and process to have realtime)

# mlock=1|0   (allow/disallow mlocking)

# allcaps=1|0 (allow setpcap functionality (dangerous!))



# enable loading of module at startup

ENABLE=yes



# parameter settings for module

PARAMETERS="gid=29"

Mira a ver si lo tienes en tu distro y si no créalo a ver si funciona

No ha funcionado, no la ha cargado al reiniciar y sigue lanzando el mismo error relativo al parámetro gid si lo vuelvo a hacer a mano.



FATAL: Error inserting realtime (/lib/modules/2.6.18-rt7/extra/realtime.ko): Unknown symbol in module, or unknown parameter (see dmesg)

dmesg:

realtime: Unknown parameter `gid'

Hablo de un 2.6.18-rt7 compilado por mí con el parche de Molnar y el realtime-lsm-0.8.7 también como parche (hay dos versiones de este , ver http://sourceforge.net/project/showfile ... _id=106645 )
Ese archivo /etc/default/realtime es el mismo que se crea al instalar realtime-lsm que es el script para manejar esto , y lo curioso es que después de instalarlo y hacer /etc/init.d/realtime start dice que :

Loading Realtime Linux Security Module: not found

Cuando sé de sobra que está ahí , algo raro debe haber pasado durante la compilación del núcleo .

Todo esto no pasa en un 2.6.17-rt8 también cocinado a fuego lento , en el que el módulo realtime se carga con normalidad con el parámetro pertinente y con pleno rendimiento , mejor incluso , creo , que el uso de PAM con la configuración de limits.conf .Aunque no podría decir "cuánto" mejor.

ivalladt escribió:
En este momento ya no es necesario utilizar módulos del tipo realtime-lsm para que las aplicaciones tengan acceso al "tiempo real". Para esto es necesario que la versión actual de libpam-modules sea igual o superior a la 0.79-4. Si usas Debian sid ya tienes esta versión instalada.

Esa versión está también en Etch :

 dpkg -l libpam-modules

ii  libpam-modules                    0.79-4        Pluggable Authentication Modules for PAM

ivalladt escribió:
Ojo, con el libpam-modules que indico realtime-lsm no es necesario y es mejor que no se cargue el módulo.

Exacto , ese (libpam-modules + limits.conf) , si no me equivoco , es el método aceptado por los desarrolladores de Linux para resolver el asunto del "realtime" en contra de la carga del módulo , que parece ser menos seguro .

"ivalladt" escribió:
¡Acabo de encontrar que te puedes bajar un kernel multimedia para x64 o 32 bits aquí!
http://archive.64studio.com/pool/main/l/linux-2.6/

Perfectamente instalable sobre Debian Etch.

Por cierto , para máquinas con más de 1Gb de RAM Etch dispone de un kernel apodado bigmem
(linux-image-2.6-686-bigmem ). Lo digo por que el que se instala por defecto no tiene activada esa opción. En mi máquina con 2Gb sólo eran reconocidos 895 Mb hasta que di con este.

Saludos.

"guitman" escribió:
Exacto , ese (libpam-modules + limits.conf) , si no me equivoco , es el método aceptado por los desarrolladores de Linux para resolver el asunto del "realtime" en contra de la carga del módulo , que parece ser menos seguro.

¡Ah!, ¿osea que si usas un kernel con el módulo realtime (y consigues que el parametro "gid" te funcione) no es necesaria la modificación de limits.conf? ¿Y lo de limits.conf lo usas con un kernel sin el parche de Molnar y va bien?

"malkavian @ 21 Ene 2007 - 09:00 PM" escribió:

"guitman" escribió:
Exacto , ese (libpam-modules + limits.conf) , si no me equivoco , es el método aceptado por los desarrolladores de Linux para resolver el asunto del "realtime" en contra de la carga del módulo , que parece ser menos seguro.

¡Ah!, ¿osea que si usas un kernel con el módulo realtime (y consigues que el parametro "gid" te funcione) no es necesaria la modificación de limits.conf? ¿Y lo de limits.conf lo usas con un kernel sin el parche de Molnar y va bien?

Según tengo entendido , rlimits "sustituye" a realtime-lsm-module , o sea , o usas una cosa o usas otra , tanto en un kernel parcheado como sin parchear ,y rlimits es la aceptada por los desarrolladores del kernel en lugar de realtime-lsm , pero me da que la cosa está avanzando cada vez más en el sentido de ir incorporando los parches de Ingo Molnar o parte de ellos en el kernel .O eso me pareció leer hace algún tiempo por la lista de correos de LAU. Y creo que el módulo realtime tiene problemas para funcionar en núcleos superiores a 2.6.17 , como antes ocurriera con los superiores a 2.6.13 ó 14 (no recuerda) por que se actualizó el parche del mismo , algo que ahora mismo no pasa.A no ser que esa yo la única persona con este problema .

Los núcleos actuales ofrecen un mejor rendimiento que los pasados sin necesidad de parches , pero con el parche el rendimiento mejora una burrada.

Si no es así, que nos lo aclare el moderardor :twisted:

"malkavian @ 21 Ene 2007 - 09:00 PM" escribió:

"guitman" escribió:
Exacto , ese (libpam-modules + limits.conf) , si no me equivoco , es el método aceptado por los desarrolladores de Linux para resolver el asunto del "realtime" en contra de la carga del módulo , que parece ser menos seguro.

¡Ah!, ¿osea que si usas un kernel con el módulo realtime (y consigues que el parametro "gid" te funcione) no es necesaria la modificación de limits.conf? ¿Y lo de limits.conf lo usas con un kernel sin el parche de Molnar y va bien?

Creo que son dos cosas distintas y que nos conviene tener ambas.

- Parches de Ingo Molnar: Convierten el núcleo en apropiativo (preemptive) de forma que las aplicaciones en primer plano tienen prioridad sobre los servicios, recomendable para cualquier equipo de escritorio.
- libpam-modules (> 0.79-4) y limits.conf: Permiten a aplicaciones que no son root acceder al "tiempo real". Si funciona en tu equipo, debes usar esto en lugar de realtime-lsm u otras opciones. Recomendable para ejecutar aplicaciones donde la latencia es crítica.

limits.conf funcionará en un equipo sin parches preemptive y viceversa, un núcleo preemptive funcionará en un equipo sin limits.conf, pero a nosotros nos conviene tener los dos.

"ivalladt @ 21 Ene 2007 - 03:46 PM" escribió:
¡Acabo de encontrar que te puedes bajar un kernel multimedia para x64 o 32 bits aquí!

http://archive.64studio.com/pool/main/l/linux-2.6/

Pues muchas gracias. Resumiendo, ¿esto sería suficiente para tener un debian óptimo para trabajo con audio en "tiempo real"?

Alguien escribió:
# su
# echo "@audio - rtprio 99" >> /etc/security/limits.conf
# echo "@audio - nice -10 " >> /etc/security/limits.conf
# echo "@audio - memlock 4000000 " >> /etc/security/limits.conf
# wget http://archive.64studio.com/pool/main/l ... 9_i386.deb
# dpkg -i linux-image-2.6.17-2-multimedia-486_2.6.17-9_i386.deb
# exit
(reiniciar y elegir en grub linux-image-2.6.17-2-multimedia)

¿los headers correspondientes sólo los necesitaría si voy a compilar algún módulo?

"Robakun @ 22 Ene 2007 - 01:32 PM" escribió:

Pues muchas gracias. Resumiendo, ¿esto sería suficiente para tener un debian óptimo ara trabajo con audio en "tiempo real"?

Alguien escribió:
# su
# echo "@audio - rtprio 99" >> /etc/security/limits.conf
# echo "@audio - nice -10 " >> /etc/security/limits.conf
# echo "@audio - memlock 4000000 " >> /etc/security/limits.conf
# wget http://archive.64studio.com/pool/main/l ... 9_i386.deb
# dpkg -i linux-image-2.6.17-2-multimedia-486_2.6.17-9_i386.deb
# exit
(reiniciar y elegir en grub linux-image-2.6.17-2-multimedia)

¿los headers correspondientes sólo los necesitaría si voy a compilar algún módulo?

Como dice el botoncito del Windows: "Sí a todo"

¿Y ahora dónde está la gracia de studio64?, qué le falta a la debian etch, dicho a todo quesí (mirar el post anterior) para ser gemela de studio64 o musix?