Probando el kernel 2.6.12.1

Pues como desde hace unos días está disponible el kernel 2.6.12.1 en kernel.org he decidio descargarlo y probarlo.

Descargo y descomprimo la última versión estable de kernel.org, y los descomprimo quedando las nuevas fuentes en /usr/src/kernel-source-2.6.12.1.

Parece ser que el archivo de configuración del 2.6.8 es válido para ésta nueva versión (en principio todos los de la serie 2.6 con compatibles), así que lo copio al directorio de las nuevas fuentes.

Esta vez uso opciones ligeramente diferentes pero cuyo resultado es el mismo:

make-kpkg buildpackage -rev MiKernel.v1 kernel_image

La versión es la 1, puesto que es la primera versión propia del kernel personalizado a partir de las fuentes del 2.6.12.1.

Tras la ejecución de make-kpkg los directorios relacionados con el kernel 2.6.12.1 son:

Documentación del kernel
-rw-r--r-- 1 root src 2,8M 2005-06-28 01:40 kernel-doc-2.6.12.1_MiKernel.v1_all.deb

Cabeceras del kernel
-rw-r--r-- 1 root src 4,9M 2005-06-28 01:41 kernel-headers-2.6.12.1_MiKernel.v1_i386.deb

Imagen del kernel para 386 (386!)
-rw-r--r-- 1 root src 5,6M 2005-06-28 01:42 kernel-image-2.6.12.1_MiKernel.v1_i386.deb

Directorio con las fuentes
drwxr-xr-x 20 root root 4,0K 2005-06-28 01:41 kernel-source-2.6.12.1

Paquete con las fuentes MiKernel.v1
-rw-r--r-- 1 root src 36M 2005-06-28 01:40 kernel-source-2.6.12.1_MiKernel.v1_all.deb

Información sobre el proceso realizadop por make-kpkg
-rw-r--r-- 1 root src 1,4K 2005-06-28 01:41 kernel-source-2.6.12.1_MiKernel.v1_i386.changes

Fuentes originales del kernel 2.6.12.1
-rw-r--r-- 1 nasz nasz 36M 2005-06-26 12:52 linux-2.6.12.1.tar.bz2


Archivo de firma de las fuentes originales del kernel 2.6.12.1 (linux-2.6.12.1.tar.bz2)
-rw-r--r-- 1 nasz nasz 248 2005-06-26 12:38 linux-2.6.12.1.tar.bz2.sign

Tras instalar los correspondientes paquetes, reinicio y recompilo los módulos extras sin problemas. Arranco y todo parece funcionar correctamente.

Los controladores de nVidia empiezan a ser algo molestos, ya que al reinstalarlos para el nuevo núcleo desinstala los controladores para el núcleo anterior, por lo que si quiero volver a usar el kernel anterior debo reinstalar nVidia para poder tener sistema gráfico. Lo lógico sería poder tener instalados varias versiones de los controladores de nVidia, una para cada núcleo, pero dado que son propietarios y que ellos deciden como hacerlo, no es posible. Fáciles de instalar si, y funcionan bien, si, pero si te quieres salir del camino marcado hay problemas.... en fin, quizá haya una manera de bajarse las fuentes o hacer una instalación manual múltiple, vaya usted a saber...

MiKernel.v6b a MiKernelV7b (ALSA)

Vengo usando OSS desde que instalé el sistema. Sin embargo OSS está obsoleto, sustituido por ALSA (Advanced Linux Sound Architecture), y ya iba siendo hora de cambiar. Sé que si no funciona no se debe de tocar, pero tenía ganas de tocar el tema del sonido.

ALSA, así como OSS, se colocan ente el hardware y los demonios, como aRts, que sirven a los programas para reproducir sónido. ALSA y OSS son una especie de controlador genérico de hardware (puesto que entre el hardware y ASLA ú OSS está el controlador específico para cada hardware).

Tras cacharrear un poco, y tirando de #debian-es de Freenode, me doy cuenta de que tengo tanto OSS como ALSA compilados en el kernel. Grave error, puesto que ámbos controlan el hardware de sonido directamente, y no pueden convivir ámbos juntos. En mi caso era OSS quién se apoderaba del hardware.

Para verlo, y en genreal para cualquier problema de detección de hardware y similar, nada mejor que echar un ojo a dmesg. Ahí se ve los dispositivos detectados y si se ha producido algún error en su inicialización.

Una vez visto el problema genero un nuevo kernel, MiKernel.v7, dejando OSS como módulo y ALSAcompilado dentro del kernel. Ya de paso activo el soprote para la consola framebuffer y el logo de carga (ese Tux que sale en la esquina superior izquierda) que, si no me equivovo, es configurable.

Dado que aún no he escrito explícitamente los pasos claro para recompilar e instalar un nuevo kernel, aquí los pongo:

• Hacer una copia de /usr/src/linux/.config para guardar la configuración actual del kernel (si no está hecha ya).


• Editar la configuración del kernel, yo lo hago mediante make menuconfig dentro de /usr/src/linux
  
• Renombrar el directorio /lib/modules/2.6.8 si estoy voy a instalar un kernel 2.6.8. Si fuese otra versión del kernel no haría falta puesto que se usaría otro directorio (/lib/modules/). De esa manera guardo los módulo del kernel antiguo por si hubiese algún problema poder volver a él sin dificultades.


• Ejecutar make-kpkg clean en /usr/src/linux para limpiar los restos de la última compilación.


• Ejecutar make-kpkg --revision=MiKernel.v kernel_image kernel_headers kernel_source para crear los paquetes .deb con la imagen binaria del kernel, las cabeceras y las fuentes.


• Una vez compilado el kernel y creado los correspondientes paquetes, que se make-kpkg los deja en /usr/src, se instalan los paquetes de imagen y fuentes. Las cabeceras no hace falta instalarlas ya que están incluidas en las fuentes (yo antes instalaba las fuentes y las cabeceras, método erróneo).
  


• Reininicar


• Recompilar el módulo de nVidia, más que nada para poder tener las X. Baasta con ejecutar el script de instalación que tengo en mi almace de software dde están controladores de nVidia que descargué de su web.


• Recompilar el resto de módulos no oficiales (los que he compilado yo, como el spca5xx de la webcam, que no vienen en el kernel oficial y por tanto no se compilan automáticamente).

Después de compialr e instalar MiKernel.v7 pruebo ALSA mediante alsaconf. Sin embargo, me avisa de que no encunetra tarjetas válidas.

Trato de ver si se ha reconocido la tarjeta:

# cat /proc/asound/cards
0 [VirMIDI ]: VirMIDI - VirMIDI
Virtual MIDI Card 1
1 [Live ]: EMU10K1 - Sound Blaster Live!
Sound Blaster Live! (rev.10) at 0xd000, irq 16

Pues parece que si. Veamos los dispositivos:

# cat /proc/asound/devices
1: : sequencer
0: [0- 0]: ctl
11: [0- 3]: raw midi
10: [0- 2]: raw midi
9: [0- 1]: raw midi
8: [0- 0]: raw midi
33: : timer
32: [1- 0]: ctl
36: [1- 0]: hardware dependent
40: [1- 0]: raw midi
51: [1- 3]: digital audio playback
58: [1- 2]: digital audio capture
57: [1- 1]: digital audio capture
48: [1- 0]: digital audio playback
56: [1- 0]: digital audio capture
38: [1- 2]: hardware dependent
41: [1- 1]: raw midi
42: [1- 2]: raw midi

Parece que también están ahí. Sin embargo, no reproduce:

# aplay /home/NaSz/ping.wav
aplay: main:508: audio open error: No such device

Me vuelvo a quedar sin ideas. Momento de recurrir al IRC, Freenode, canal #alsa:
Now talking on #alsa
* Topic for #alsa is: Advanced Linux Sound Architecture || Unprofessional, unofficial support, see WIKI at http://alsa.opensrc.org/
* Topic for #alsa set by jcdutton at Mon Aug 23 00:38:12 2004
NaSz: hi
NaSz: I'm trying to get alsa working on Debian 2.6.8 kernel
NaSz: I've compiled the kernel with alsa built in and oss as modules
NaSz: now /proc/asound/cards and /proc/asound/devices show me my SoundBlaster Live! using emu10k1
NaSz: but when I test it with aplay I get "aplay: main:508: audio open error: No such device"
pzad: NaSz: look at /dev/snd/* if there are device files
NaSz: yes, a lot of files
pzad: what is in /proc/asound/cards
NaSz: # cat /proc/asound/cards
NaSz: 0 [VirMIDI ]: VirMIDI - VirMIDI
NaSz: Virtual MIDI Card 1
NaSz: 1 [Live ]: EMU10K1 - Sound Blaster Live!
NaSz: Sound Blaster Live! (rev.10) at 0xd000, irq 16
pzad: try
pzad: aplay -D plughw:1 some.wav
pzad: and alsamixer -c 1
NaSz: hey! it sounds!
pzad: did you compile alsa as modules or in to kernel
NaSz: in to kernel
pzad: your problem is virtual midi module - it is as first card and sb live is second
pzad: you can specify order of soundcards in kernel command line at oot time
pzad: for example snd-intel8x0.index=0 snd-emu10k1.index=1
NaSz: wich names I must use?
pzad: I think for you snd-emu10k1.index=0 snd-virmidi.index=1

Es decir, que el primer dispositivo de sonido es el MIDI virtual, que evidentemente no tiene las capcacidades de una tarjeta de sonido, por lo que alsaconf falla, ya que debe de usar el primer dispositivo que encuentra.

Es similar a lo que me pasaba con el soporte UltraDMA: se cargaban primero los controladores IDE genéricos que no tenían soporte para UltraDMA, y después los específicos para mi hardware, pero el núcleo usaba los primeros, por lo que no tenía UltraDMA.

Para solucionarlo se puede, como comenta pzad, pasarle unos parámetros al kernel de manera que coloque los dispositivos en un orden determinado, o recompilar el kernel eliminando el dispositivo MIDI virtual.

Decido que lo mejor es recompilar el kernel eliminado el soporte para el MIDI. Reconfiguro, recompilo, instalo, reinicio y compilo los módulos necesarios. Ejecuto alsaconf y ésta vez funciona. Abro el KDE y el sonido de bienvenida me indica que también funciona, como era de esperar, en KDE.

Nota: Dado que ya no uso ndiswrapper para la conexión inalámbrica, podría recompilar el kernel de nuevo con pilas de 4K en vez de 8K (los controladores de Windows que usaba ndiswrapper gustan de las pilas de 8K, pero con 4K se obtiene un rendimiento mayor del sistema).

Archivos Musepack (MPC) en XMMS

Para reproducir archivos MPC con xmms basta con instalar la extensión (plugin) xmms-musepack.

Descargar, compilar como usuario, copiar el fichero xmms-musepack-1.00.so en el directorio ~/.xmms/Plugins y reiniciar el XMMS.

Lo más extraño es que el archivo de instalación que acompaña a la extensión parece corresponder a una versión para Windows; habla delWinAmp, de copiar el fichero xmms-musepack-*.dll, pero funciona.

Para otros programas se puede instalar directamente el paquete libmpdev3.

Videconferencia con aMSN: probado y funcionando

Había probado la webcam con el aMSN un par de veces, pero no había funcionado. No sabía si era una ceustión d epuertos abiertos, de que el aMSN no reconocía la cámara o de que la alineación planetaria no era la correcta.

Asi que fui meticulosamente.

La primer fuente de información interesante para éstas cosas es el wiki del aMSN. Ahí hay información actualizada sobre el aMSN. Especialmente interesante es la página sobre webcam con aMSN. En ella se comenta, aparte de otros problemas, como probarla cámara con aMSN:

Now you can go to your /msn/utils/linux/capture/ directory and type "./test.tcl" in a console.

Efectivamente a mi me funciona (está en /usr/share/amsn/utils/linux/capture).

Ahora los puertos. Es necesario abrir los puertos TCP y UDP desde el 6890 hasta 6900. Por lo que he podido leer, éstos sirven para enviar y recibir ficheros, siendo el número de dichos puertos abiertos el límite al número de transferencias que se pueden realizar, hsat un máximo de 10. Sin embargo, en la página del wiki de aMSN parecen querer decir que también son necesarios para la videoconferencia.

Por otro lado he leído que se deben abrir desde el puerto 5000 UDP hasta el 65535 para videoconferencia. No me agrada abrir semejante rango de puertos, pero al ser UDP, y al no haber servicios detrás, acepto. Tendré que estudiar si realmente es necesario.

Hoy por fin he vuelto a probar, y está vez ha funcionado perfectamente. Va un poco lento, pero va. He probado aque me visen amigos con ADSL sin webcam y ellos me veian. Luego he probado con una amiga que si tenía webcam y nos veíamos ambos, pero iba muy lento, incluso el sistema estaba ralentizado. Vaya usted a saber por qué.

Webcam con clientes de MSN Messenger

Las pijaditas siempre dan vidilla, y el poder ver a mi colega PeZeta que está al otro lado del charco siempre siente bien. Comentando en #debian-es de los servidores debian, me dicen que al menos la última versión (0.95) del amsn (Alvaro's Messegner) admite videoconferencia con clientes de MSN Messenger. Además, compila no hace falta tener paquetes de la distribución en desarrollo.. ¡una ganga!

También se comenta que gaim-vv permite videoconferencia, pero creo recordar que era sólo con yahoo.

En la página oficial de aMSN figura hasta la 0.94, así que me pasan el enlace, que no es más que la versión CVS. Descargo, y trato de ejecutar (viene con un binario). Error. En los ficheros de ayuda se comenta que me hace falta tcl y tk. Bien. Instalo ambos, incluida la versión de desarrollo por si quiero compilar.

Compilo y ejecuto. Funciona.

Jugando con él, experimentaba culegues aleatorios, muy molestos, sabía que usaba una versión de desarrollo, pero aquello era un desfase. Buscando mucho, econtré la página de problemas conocidos del wiki de amsn. En ella comentan:

Description: Some people is experimenting random hangs when using AMSN on Debian and Linux Kernel 2.6 It looks like the problem is caused because of the new threads model in the 2.6 kernel.

Workaround: You can stick to kernel 2.4 until this is fixed, probably not in the kernel, but in AMSN or in the new versions of the Tcl interpreter. We're working with the tcl/tk team to have this fixed.

It looks like these hangs only happen with Linux Debian using Kernel 2.6 and TCL 8.4, so downgrading to TCL 8.3 fixes this.

Also, you can download tcl/tk 8.4 sources from http://tcl.sourceforge.net, and build them yourself, making sure you DON'T enable the --enable-threads option when running the configure script. Without this option, amsn will run just fine.

Another possible solution is to launch amsn with:

export LD_ASSUME_KERNEL=2.2.5 && msn/amsn

to tell the dinamic linker to use the old thread model.

Así, por el momento lo ejecuto con el comando export LD_ASSUME_KERNEL=2.2.5 && amsn. Mientras me he entretenido bajandome unas pieles y echando un vistazo a la página web del amsn.

Mi cámara. Reviso mis envíos...vaya, debía de haber explicitado más, no queda claro como lo hice. Bueno, son necesarios dos módulos, videodev y spca5xx para que funcione.

modprobe videodev
modprobe spca5xx

El primero va fino, pero el segundo parece que no lo encuentra. Lógico, pués al haber recompilado el kernel los módulos adiconales que he añadido yo los tengo que volver a compilar. No estaría de más hacerse un script que los compilase junto al kernel. Basta con ir a /usr/src/modules/spca5xx-20050407/ y hacer make clean, make y make install.

Sólo queda probarla después de cargar el módulo de la cámara y probarla con spcaview. A la primera lo probé como root, se pusó en pantalla completa y no salió de ahí, se me colgó. Mientras arreglaba el desaguisado mi único contacto conectado se ha ido a dormir. No lo puedo probar, tendré que esperar a mañana.

Notas sobre posibles bugs:
Casca si se abre el programa con la cámara concetada y encendida como webcam.
No abre me abre un fichero como avatar, sospecho que por que lleva ñ. Quito la ñ y ya va.

El encumbramiento y la caida del D-Link DWL-G122

Esta es la triste historia del interfaz de red inalámbrico D-Link DWL-G122.

Una vez compilado el kernel, me dispuse a usarlo. Hice un bonito envío con todos los detalles pero se perdió (los de blogger tienen que depurar su sistema de edición, a veces falla se pierde lo escrito), así que ahora estoy vago y con pocas ganas de volver hacerlo.

En resumidas cuentas, una vez compilado el ndisWrapper se debe instalar el controlador de Windows, y luego configurar el acceso de red inalámbrico. Dejo un enlace a un artículo en badopi que comenta todo esto, ya que yo he perdido las ganas de hacerlo.

Tuve unos días felices en los que accedía a mi router de manera inalámbrica, sin problemas, pero era un espejismo. En seguida empezaroin los problemas, las desconexiónes, respuestas extrañas, cuelgues aparentes del router y demás paranoias. Quisé achacarlo al router, a Jazztel, pero cuando empezaron los cuelgues del sistema me convencí de era el controlador de la red inalámbrica.

Por suerte tengo el rotuer cerca del ordenador y puedo tirar de cable. Como no es un portatil no importa, no lo voy a mover.

Una pena, habrá que esperar a que ndisWrapper madure, o ver otras opciones. Tengo que preguntar a ver si hay una manera razonable de depurar mi sistema para ver si puedo ver por qué se cuelga, y así echar una mano al desarrollo de ndiswrapper.

Por el momento sigo tirando de cable ethernet.

Volcando CDs al disco duro

Ahora que tengo el ordenador definitivamente instalado en casa es momento de ir pasando a MP3 unos cuantos de mis discos. Usaría Ogg Vorbis, pero mi reproductor MuVo no lo admite. Según he oído, aducen que decodificar el formato Ogg exige un mayor consumo de energía por lo que las baterías durarían mucho menos. Yo, por mi parte, preferiría que me durase menos la batería y poder tener mi colección de música en Ogg, pero por el momento no va a ser posible.

Hay un manual de grabación digital de música hecho por acs en el que comenta las nociones básicas.

Yo por mi parte voy directamente a lo mío.

Para extraer uso cdparanoia, que bien con grip. La codificación la hago con lame. Debido a liíos de licencias y demás historias, lame no pude ser distribuido como binario, por lo que no está disponible mediante apt. Desde la página de lame descargo la última versión (3.96.1). Descomprimo, compilo e instalo (./configure, make, make install). Al principio obtengo un error debido, aparentemente, a que el script de compilación no soporta espacios en la ruta o rutas muy largas. El hecho es que moviendo todo a /tmp me compiló sin problemas.

A grip hay que pasarle los parámetros que usará con los programas auxiliares que le ayudan a ahcer su trabajo. En el caso de cdparanoia nohace muhca falta ya que está muy integrado con grip, pero para el lame hay que especificarlos. Pretendo codificar en MP3 a ratio de bits varaible (VBR), con Joint Stereo y con bastante calidad. Así, el comando será:

lame -V 2 %w %m

%w indica a grip que debe ser sutituido por el nombre del archivo wav en proceso.
%m indica a grip que debe ser sutituido por el nombre del archivo codificado en proceso.
-V 2 indica a lame que debe codificar usando ratio de bits variable con calidad 2 (entre 9 y 0, siendo 9 la peor y 0 la mejor). Eso implica, viendo el manual, que usará joint stereo.

Hay que especficiar también como se llamarán los ficheros. Para eso se usan esas 'variables' de grip que contienen el nombre del wav o el nombre del fichero codificado. Éstas variables son:

b — The bitrate that files are being encoded at.
c — The CDrom device being used.
C — The generic scsi device being used (note that this will be substituted with the CDrom device if no generic scsi device has been specified).
w — The filename of the wave file being ripped.
m — The filename of the file being encoded.
t — The track number,beginning at 1, and zero-filled (ie: '03' for the third track).
s — The start sector of the track.
e — The end sector of the track.
n — The name of the track.
a — The artist name for the track.
A — The artist name for the disc.
d — The name of the disc.
i — The disc database id (in hex) for the disc.
y — The year of the disc.
g — The ID3 genre id of the disc.
G — The ID3 genre string of the disc.
r — The recommended replay gain for the track (in dB). Note that this is only applicable if you have enabled gain calculation. You can find more information on this gain adjustment at www.replaygain.org
R — The recommended replay gain for the entire album (in dB). This value is only valide after an entire disc has been ripped (it is designed to be used with the disc filter command).
x — The encoded file extension (ie "mp3")

Así, mis ficheros mp3 finales serán:

~/rips/mp3/%A - %d (%y)/%t - %n.%x

De manera que quedan organizados en discos, con el año de grabación indicado.

Por último quisiera aplicarles normalización. Según lo entiendo yo lo que quiero es subir el volumen de las pistas hasta el máximo posible pero sin altera la relación entre los diferentes volúmenes de las partes de la canción. Para ello usaré la normalización mediante picos, es decir, calcular el máximo nero de decibelios que puede ser subido el sample má alto (el mayor pico) y subir todos los samples esa cantidad. Para ello se utilza el programa normalize (apt-get install normalize) al que llamo mediante grip en la opción 'comando de filtro wav' de la pestaña extraer, que llama a un comando después de cada extración. Quedaría así:

/usr/bin/normalize %w --peak

Ah, y no olvidar activar la opción de las etiquetas ID3 para que el fichero lleve los datos de la canción, que serán obtenidas a través un servidor cddb.

Por último, un enlace que muestra las opciones de ejecución de lame.