HACK THE SYSTEM: Problemas de sonido con Pulseaudio... el conocido ratelimit.c en /var/log/messages

RSS

 Seguime por RSS

23 abr 2011

Problemas de sonido con Pulseaudio... el conocido ratelimit.c en /var/log/messages

Que tal mi primera entrada, espero les sirva , comentarios, puteadas abajo en comentarios y contesto, si dejás un mail falso no te podré contestar, primera y única aclaración.

Bueno, muchos reportan en bugzilla.redhat.com,  que contrató al pibe este lennart que hizo pulseaudio, sobre un ratelimit.c o el conocido "nos desperto un pollin", ok, y siguieron el bugtracker y nunca les dieron una solución, y lo más seguro crean que es el kernel o pulseadio, o cambiaron de placa de sonido pensando que con otro modelo era mas compatible, en teoria si, pero si no es HD, high definition audio.
Primero, que es un timer?:
Todo dispositivo electrónico, teclado, mother, memorias, LCD, etc, posee lo que se llama un CLK GEN, o en castellano, un clock generator, para?, bueno, esto es básico, es como un marcador usado por un músico, necesita ser marcado un ritmo de forma constante acorde a su necesidad, y no todos los IC (Circuitos Integrados), poseen las mismas especificaciones, por tanto, los clock no son los mismos para todos, ok?, por ej.: un teclado posee un clock de 10HZ, bajo, total.. nadie tipea tan rápido para superar eso.
El CPU mismo usa, TSC, o bien HPET que son los mas conocidos, en sistemas como Windows se usa HPET, high precision timer, one shot llamado en Linux internamente, esto le marca al CPU los clock de software, en la entrada de compilación de kernel, veran que existe una opción dentro del mismo llamada timer frequency, pueden poner desde 250 a 1000Mhz, esto es según el uso y el CPU, para un server, 300HZ es aconsejado, para un Real Time Kernel como un desktop, se usa 1000HZ, siempre y cuando sea mayor que un P2.
Entendido esto, repasemos:

Mi placa de video usa timer?, Si
Mi Teclado?, Si
Mi CPU?, Si

Ok , todo usa timer, entonces, mi placa de sonido también, asi es, lo usa, y ahi viene el problema.
El kernel linux provee el modulo de sonido segun la placa, el mas comun que falla es el snd_hda_intel, que aplica a las placas con IC Analog Devices, asi como las las Realtek, Cmedia y más.
Este modulo interactua en una capa mas alta con el servidor de sonido ALSA, segun su web, el driver de HD para intel Azalia, es como el AC97, un standar, lo hizo "unknow", ok, mucha seguridad me da esto... LOL
Luego, uno cree que cambiado el kernel mejora, y asi es, con kernel viejos anda bien, pero porque?, y bueno, no usaban HPET, y el modulo tenia un codigo distinto, pero, que cambió?
A ver, cambio que usamos kernel que vienen en 1000HZ, usan HPET, TSC y demás, entonces el mas mínimo fallo repercute mas en todo el sistema.
ALSA, usa timer por soft para marcar el paso junto al IC de sonido, pero el driver esta fallado, asi es, fue reportado por mi y mas gente, pero se ve que NO les interesa, asi que, al usar solo ALSA, no vemos ningun error, porque vamos, alsa es solo 44100 y un sonido unico, no es fullduplex.
Al usar Pulseaudio, que es un servidor de sonido que corre como daemon, o demonio, le sirve de sonido a multiples aplicaciones valiendose de lo que entrega ALSA, requiere mas cosas, mas precisión y es mas complejo, la versión actual, no tiene ningun fallo, el problema radica en ALSA, al estar MAL hecho el driver de snd_hda_intel, y marcar mal el timer, cuando usamos cosas como pulseaudio, con Skype 2.2 por ej, en vez de 40 eventos suprimidos tenemos 4000, hasta se puede freir el CPU en consumo o congelar el sistema en un hardlock, no olvidemos que estamos tratando mal a los timer, no es poca cosa, es bajo nivel.
Ok, ahora que explique que pasa, es, como lo arreglo?, simple, decimos a pulseaudio que NO use timer, porque por defecto lo usa, y como el de ALSA le entrega mal las cosas, se desborda y termina haciendo estragos, como hacemos esto?, ok, abrimos un terminal, nos logueamos como root, y luego editamos:

nano /etc/pulse/default.pa y buscamos la linea esta:

load-module module-udev-detect

Al final de ella, colocamos tsched=0, quedaria asi:

load-module module-udev-detect tsched=0

Con eso le decimos a pulseaudio que no use timer scheduler, reiniciamos la pc y nunca mas problemas de sonido, esto aplica a TODAS las distro linux que usen pulseaudio.

Espero les sirva, saludos, bytes.

2 comentarios:

  1. Muchas gracias por este workaround. Este problema de ratelimit me generaba cuelgues aleatorios y este es el único lugar en el cual encontré una solución. Aprecio mucho tu aporte.

    ResponderEliminar

Dejá tu comentario