ORDENATA DE LA GARRAXI "KRISTON-SERVIDOREA": SOFTWARE: XFREE: Las X, para que arranquen hay que cambiar la configuracion un poco: - 4.x: En section "Device" del XF86Config-4 que hice para el antiguo ordenata, poner como nombre el de la tarjeta y como Driver "cirrus". Pruebo tambien diversas resoluciones y profundidades de color, pero con la resolucion de 1024x768 y la pantalla Targa parpadea bastante, asi que la dejo en 800x600 y 24 bpp. - 3.3.6: Instalo el paquete xserver-svga-v3 de la Woody, rehago la configuracion de XF86Config con xf86config-v3 y añado alguna cosa mas con ayuda del archivo /usr/share/doc/xserver-common-v3/README.cirrus.gz. Despues comparo la configuracion antigua con la nueva y añado los temas de powersaving, el control de las teclas que cambian de resolucion y de consola, etc. Realizo pruebas con distintas tasas de refresco para la pantalla y resoluciones y la dejo a 800x600 y 16 bpp. Finalmente (lo mas imp) arranco las X con startx -- -bpp 16 (otras posibilidades -bpp 24 y 32, ver archivo README.cirrus.gz). Esto lo pongo en ~/.bash_profile. Cambiarlo para utilizar las X 4.x. Comparacion consumos memoria: PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 732 root 15 0 8380 6260 2304 S 1.3 6.4 0:55.77 /usr/X11R6/bin/X (X 3.3.6) 888 root 15 0 14904 12580 2140 S 4.0 10.2 0:10.50 /usr/bin/X11/X (X 4.3) Con las X 4.3 se nota al gestor de ventanas andar mas ligero, y mas facil. Con las 3.3.6 es como menos "responsivo", aunque consuma menos memoria (ahora eso es menos problema con 500 Mb). Tambien es un rollo andar cambiando porque con las 3.3.6 las fuentes de las aplicaciones gtk2 y las de IceWM se ven mucho mas pequeñas y hay que reconfigurarlo (en icewm se tocan los tamaños de letra puestos al final del archivo theme). Asi que dejo las X 4.3. En cuanto a los iconos de escritorio: - Al principio tenia Xtdesktop, porque son solo iconos, gastan pocos recursos y no se pueden mover facil en el escritorio (ver info-software-garraxi1). - Pero me doy cuenta que los luser necesitan un gestor de archivos al estilo del de las ventanas por cada carpeta de windoze. Asi que cambio xtdesk por Rox-filer, que gestiona los iconos de escritorio, la imagen de fondo del escritorio (tambien quito xli del .xinitrc), gestiona los archivos, permite usar el escritorio como un "contenedor de archivos" (oh, noooo!!), etc. - De todas formas Rox es bastante diferente que el gestor de archivos de windoze, por lo que puede ser tambien un poco lio. Ademas los iconos de Rox son mas feos porque no permiten utilizar varias lineas en la descripcion del icono (al menos en la version de Sarge: 2.2.0-2). - Asi que en el futuro igual PRUEBO UN ESCRITORIO COMPLETO, LIGERO Y COSTUMIZABLE COMO EL DE XFCE. - El consumo de memoria pasa de 2.848Kb con xtdesk a 8.512 Kb con rox. ENDEAVOUR2: Una buena feature de endeavour2 es la posibilidad de hacer que el arbol de directorios empiece donde quieras. Le he puesto que empiece en /home/garraxi y asi solo aparecen las carpetas donde el usuario puede guardar cosas. Para mostrar todo se puede volver a cambiar el origen del arbol, pero al volver a arrancar el programa vuelve a salir el guardado en la configuracion (que esta protegida y no se puede modificar). Asi lo he puesto tambien en las imagenes de la ayuda. Para guardar en la configuracion el origen del arbol, lo cambie cuando tenia desprotegido /home/garraxi/.endeavour2/endeavour2.ini, quite el programa para que se guardara esa caracteristica y luego protegi el archivo pasandolo a garraxi2. Otra feature interesante es la de mostrar el uso del disco para todos los discos dados de alta en la ventana de Dispositivos. El programa mira 1º en /etc/fstab y despues completa la info con lo que hay en esa ventana (guardado en el archivo /home/garraxi/.endeavour2/devices.ini). De esta manera, para que funcione bien, el punto de montaje tiene que estar puesto en ambos sitios, no solo en la config de endeavour. Pero hay un problema con el supermount, que hace que todos los puntos de montaje con supermount tengan de dispositivo "none" en lugar de /dev/algo, en fstab. De esta manera endeavour se hace un lio y solo entiende bien uno de los puntos de montaje con supermount (uno de los "nones"). Para arreglarlo basta con poner en fstab a cada uno de los "ptos de montaje" de supermount un none1, none2... y asi todos los que haya, de manera que son nombres diferentes y asi endeavour lo entiende bien. Despues poner en devices.ini la info acorde a esto a traves de la configuracion del programa. Otro asunto con los dispositivos es que el programa "permite" (aunque luego de errores) montarlos y desmontarlos. He puesto a todos que no se puedan montar y desmontar (posibilidad que da tambien la ficha de dispositivos), para que no se pueda hacer con los puntos de montaje normales (los del almacen de musica...) y para que no haya errores con los que tienen supermount. El sistema de mime-types del endeavour es complicado porque utiliza una mezcla de sus propios mimetypes (en menu vista) y los del archivo /etc/mailcap. Asi, para configurar las opciones posibles que se dan para abrir un archivo con boton derecho/Abrir con, se utiliza la ventana de mimetypes del programa. Pero la opcion por defecto parece tomarla siempre del archivo /etc/mailcap, por lo que hay que tocar este. /etc/mailcap tiene al principio del archivo una seccion "User Section" donde se deben de poner los mimetypes especificados por el usuario para todo el ordenata. Asi, lo que hago es copiar todas las posibles definiciones de tipos de archivo a esa seccion, y en ella les pongo que se abran con la aplicacion que quiero que sea la por defecto para Endeavour. En el caso de abiword, la definicion del tipo de archivo esta en /etc/mailcap, pero no en /etc/mime.types, y tiene que estar en los dos (en este ultimo con la extension del archivo, creo). Asi que añado a /etc/mime.types del ordenata auxiliar la definicion de application/x-abiword. En el servidor las modificaciones del mailcap son menores que en el auxiliar, porque en el primero no tenemos aplicaciones de edicion de texto y tal. Por eso, ambos mailcaps no son iguales (no copio el del auxiliar en el servidor porsia). SISTEMA SONIDO: La tarjeta de sonido ISA (Creative Vibra 16X PnP) la reconoce sin problemas desde el principio sin hacer nada (con OSS). Esto debe de ser asi por que la placa base permite que se reconozca las ISA sin tocar nada de la BIOS. Bien!!! El problema viene cuando al usar flrec para grabar sonido este da problemas en las pausas, que tras pausarlo, al intentar volver a grabar se para y dice que se ha producido un 'SIGCHLD from sox'. Ademas, al utilizar la posibilidad de este para autodectetar la configuracion optima de la tarjeta, dice que las settings que encuentra son (entre parentesis los valores habituales): - Max Freq: 44100 (48000) - Data Size: 16-bit (16-bit) - Channels: mono (stereo) Leyendo doc por ahi, en /usr/share/doc/HOWTO/es/HOWTO/Compatibilidad-Hardware-Como.html y en /usr/share/doc/HOWTO/en-txt/Hardware-HOWTO.gz dice que la tarjeta esta soportada por OSS, pero: * Creative ViBRA16X PnP (half duplex only) Osea que solo funciona como half duplex. Esto quiere decir que tiene capacidad para emitir y recibir sonido, pero no a la vez (esto ultimo seria full duplex). Pero no dice nada de que funcione solo en mono y tal. Asi que pruebo con ALSA, a ver si hay mejor soporte. Instalo los modulos: alsa-base alsa-modules-2.4.27-2-386 alsa-oss alsa-utils (para el kernel 2.4.27-2-386) y lo hago andar para ese kernel: 1. alsaconf: detecta la tarjeta de sonido ISA sin problemas y genera la configuracion necesaria 2. xmixer: para poner a punto los diferentes volumenes 3. 'alsactl store': para guardar la configuracion (como root). 4. modconf: aun asi tengo que correr modconf para descargar los modulos de OSS (que se activaban desde /etc/modules, creo) y cargar los de alsa (snd-sb16). Despues de hacerlo asi se coloca ese modulo en /etc/modules y se carga desde el arranque. Con esto consigo una mejor calidad de sonido con la tarjeta Vibra, dado que ahora flrec reporta que: - Max Freq: 496000 - Data Size: 16-bit - Channels: 4 chanels !!! Haciendo prueba de sonido al oido, se aprecia mejor calidad de sonido con ALSA que con OSS. Ademas, la doc de ALSA dice que tiene soporte full duplex para todas las tarjetas soportadas por el sistema (ver alsa-faqs). PROBAR A GRABAR Y EMITIR A LA VEZ POR LA MISMA TARJETA. Por otra parte, usando ALSA, y con las siguientes settings, el flrec graba sin los problemas de las pausas anteriores: - In device: /dev/dsp - Out device: /dev/dsp - Tipe oosdsp: (poniendolo a ALSA da problemas de que no encuentra los dev y tal) - Max freq: 96000 - Data Size: 16-bit - Channels: 4 chanel (Los 3 ultimos tomados de la autoprueba). Despues hay que compilar soporte ALSA para el kernel 2.4.23 que compile yo. Para eso utilizar el paquete alsa-source, que esta pensado para compilarte los modulos (del tipo alsa-modules-2.4.27-2-386) para el kernel que tengas. Mientras no lo hice, con el kernel 2.4.23 el sonido salia por defecto con OSS dado que se cargaba el driver OSS compilado dentro del nucelo (los modulos de ALSA trataban de cargase y daba error porque no estaban presentes). Para compilar los modulos de ALSA uso el siguiente procedimiento (en mi ordenata, con entorno de compilacion adecuado): ------ 1. Instalar paquete alsa-source 2. Hacer 'dpkg-reconfigure alsa-source' as root para seleccionar los modulos de las tarjetas de sonido que se compilaran. Resultado en /etc/alsa/alsa-source.conf. 3. Tener el kernel source tree necesario en /usr/src 4. Configurar adecuadamente el kernel source tree. Para ello coger el config guardado de la compilacion del kernel y hacer: - Desde dir /usr/src/linux hacer: make xconfig - Copiar config a /usr/src - Cargar config con el boton Load configuration from file. - Dar a Save and Exit para acabar la configuracion del kernel. Se genera el archivo /usr/src/linux/.config. Posiblemente pueda valer tambien con copiar la configuracion guardada a /usr/src/linux/ con nombre .config. 5. Extraer /usr/src/alsa-driver.tar.bz2 (puesto ahi en la instalacion del paquete alsa-source) con tar jxf alsa-driver.tar.bz2. 6. Entrar en dir /usr/src/linux (kernel source tree). Compilar modulos ALSA con 'make-kpkg --rootcmd=fakeroot modules-image' (lo he hecho como root, no he probado con fakeroot o como usuario a secas). Compila y crea el paquete alsa-modules con las versiones del kernel compilado por el kernel source tree (y su subversion y tal) + la version de ALSA. - Es buena idea primero compilar el kernel adecuado (por ejemplo quitando los "modulos" de OSS, y despues compilar los modulos de ALSA (de manera que se usara exactamente la misma configuracion del kernel). ------ Con esto creo una primera version de los modulos (garraxi3) con solo la sb vibra ISA compilada. Instalo el paquete con los modulos de ALSA en el ordenata de garraxi y arranco con el kernel compilado por mi. El resultado es que 1º se cargan los "modulos" de OSS integrados en el kernel, y despues tratan de cargarse los modulos de ALSA, con lo que la tarjeta de sonido da errores y no funciona. La solucion es compilar un kernel sin "modulos" de OSS (que tenga solo la opcion global de sonido y nada mas) y compilar despues los modulos de ALSA. Compilo asi el kernel y los modulos ALSA para la tarjeta vibra (ambos con version garraxi4) y el resultado es OK. Al reiniciar se detecta la sb vibra ISA y despues se cargan los modulos de alsa para ella (no queda reflejado en dmesg, pero se puede ver en el inicio, y despues los modulos cargados con lsmod). Para ver las caracteristicas de la tarjeta y tal se puede mirar en /proc/asound. Asi por ejemplo haciendo 'cat /proc/asound/card0/pcm0p/sub0/hw_params' se ven las caracteristicas de harware de la tarjeta, tal y como estan soportadas por ALSA: stereo + rate = 44000 garraxi@garraxi:~$ cat /proc/asound/card0/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 1024 buffer_size: 16384 tick_time: 10000 OSS format: S16_LE OSS channels: 2 OSS rate: 44100 OSS period bytes: 4096 OSS periods: 16 OSS period frames: 1024 Mirando las settings de flrec con este entorno, sigue dando las maximas posibilidades con la autoprueba: - Max freq: 96000 - Data Size: 16-bit - Channels: 4 chanel Tambien sigue funcionando bien, ya no tiene el problema de las pausas de antes. Mas tarde compilo el kernel y los modulos de alsa en version garraxi6, con soporte para la "nueva" tarjeta PCI Ensoniq, mas los de la ISA sb16. Con dos tarjetas de sonido, las configuro para que /dev/dsp=/dev/dsp0 sea siempre la que emite sonido (independientemente de que tarjeta sea, eso se define en /etc/modutils/sound, ver arriba) y /dev/dsp1 sea la que grabe; y configuro las aplicaciones para que se adapten a eso. En realidad asi definido solo hace falta configurar las aplicaciones que van a grabar (que deberan usar /dev/dsp1), porque las demas (las que van a emitir sonido) ya usan el dispositivo por defecto /dev/dsp. De esta manera, configuro audacity, en la ficha de preferencias, y sobre todo flrec, que es el programa que se llama para grabar desde los scripts de grabar cuñas y grabar programas. Dejo configurado flrec y protejo el archivo de configuracion ~/.flrec para que no se pueda modificar (asignandolo al usuario garraxi2). El unico problema que puede dar es si el usuario toca las configuraciones cuando se arranca el flrec, pero si lo quita y lo vuelve a arrancar volveran a estar las buenas. Otro asunto es el del mixer de las tarjetas de sonido. Los dispositivos para esto son /dev/mixer=/dev/mixer0 (el por defecto) para el de la tarjeta que emite, y /dev/mixer1 para el de la tarjeta que graba. De esta manera, cuando arrancamos xmixer normalmente nos presenta el mixer de la tarjeta que emite. Si es necesario modificar el volumen de grabacion hay que arrancar xmixer con el dispositivo /dev/mixer1, asi: xmixer -device /dev/mixer1 Otros mixers instalados mas potentes son alsamixer (para consola) y aumix (grafico, en gtk2). En alsamixer para elegir la tarjeta que graba hay que llamarlo con '-c1'. En aumix con '-d /dev/mixer1'. Este ultimo lo utilizo para configurar volumenes porque presenta una interfaz sencilla y con indicacion numerica del volumen. Pero esto solo lo puede hacer el Admin de la emision (ver abajo). Para diferenciar un mixer del otro en la interfaz de xmixer, el de la tarjeta Ensoniq dice algo de 'TriTech TR28602' abajo cuando arranca (luego desaparece) y no tiene controles de graves y agudos. El de la tarjeta SB16 dice 'CTL1745' y tiene control de graves y agudos a la izquierda, junto al de volumen general (aunque creo que no funcionan apenas). El sistema de ver los tipos de controles es el que se debe de usar tambien para Aumix, aunque he puesto imagenes de ambos en la Ayuda. Tras poner en marcha 2 tarjetas de sonido, compruebo que oss-preserve esta guardando la configuracion del mixer solo de la 1º tarjeta de sonido. Miro la doc del programa para configurarlo para las 2 tarjetas y no encuentro nada. Asi que miro la configuracion de ALSA para guardar las configuraciones. La configuracion para que ALSA guarde automaticamente las settings al apagar el ordenata esta en /etc/default/alsa, poniendo alsactl_store_on_shutdown="always autosave" (por defecto estaba "never autosave"). Compruebo que esto funciona para las dos tarjetas igual, por lo que desinstalo oss-preserve. Por otra parte, leo en la doc de alsa (/usr/share/doc/alsa-base/driver/Procfile.txt.gz) que para tener estadisticas del sistema de sonido compatibles con las del OSS (y que por tanto aplicaciones como gxproc que da informacion del sistema, las muestre) hay que hacer un enlace simbolico en /dev/sndstat que apunte a /proc/asound/oss/sndstat. Asi lo hago y con el kernel 2.4.23 aparecen las caracteristicas de las tarjetas y tal en gxproc (con el 2.6.x antes ya aparecian, porque el kernel 2.6 crea devices en /dev bajo demanda segun se necesitan, y se ve que creaba este). VARIOS SONIDOS A LA VEZ: Tal y como teniamos configurado el sonido no era posible poder enviar el sonido de varias aplicaciones a la vez a la tarjeta de sonido. Esto era porque las aplicaciones se conectaban directamente a la tarjeta de sonido y hasta que una no la "soltaba" el otro programa no podia comunicarse con ella. Para evitarlo se utiliza un programa que se interpone entre las aplicaciones que emiten sonido y la tarjeta de sonido. De esta forma, este programa (servidor de sonido o sound daemon) recoge todos los sonidos que le llegan, los mezcla y los envia mezclados a la tarjeta. La idea era hacer mas facil el cambio de una aplicacion de sonido a otra, por ejemplo, no tener que parar el Somad para poder empezar a utilizar el Glurp, poder pararlo justo despues de que ha empezado a utilizarse el Glurp y asi no tener que depender de los CD's para hacer el cambio. Los sound server probados han sido esound, arts, mas y yiff. Finalmente el que utilizamos es esound (Enlightened Sound Daemon, tambien conocido por sus siglas esd). Arts daba bastantes mas problemas que esd (no funcionaba ni Mixxx ni Glurp) y ademas seguia necesitando tener esd en funcionamiento para que funcionara alsaplayer+soma. Mas no he logrado entenderlo porque los paquetes que hay en Sarge (mas-server, mas-utils y libmas0) no tienen nada de documentacion. El Yiff (paquetes yiff-server y liby2-14) parece requerir que se utilicen con el programas compatibles (lo dice en su archivo de documentacion config.htm). ESOUND: es un demonio que tiene la posibilidad de arrancarse cuando alguna aplicacion lo necesita. Para ello ir al fichero /etc/esound/esd.conf y poner la linea 'auto_spawn=1' (esta por defecto a 0). Las otras opciones del fichero indican que: esd terminara cuando salga el ultimo cliente que lo este utilizando (-terminate), no se emitira ningun sonido cuando esd arranque (-nobeeps), y que liberara la tarjeta de sonido tras n segundos de inactividad (-as 5, que es lo que viene por defecto). Mas tarde pongo '-as 2', para que el esd espere menos tiempo para morir (2 seg.), de manera que de menos problemas el re-arrancar aplicaciones que puedan dar problemas de utilizar la misma instancia de esd. Ademas en varios foros de inet he visto que lo ponian asi. En garraxi tengo que instalar el paquete esound (esound-clients y esound-common ya estaban). Y ademas cambiar la libreria libesd0 (para OSS, que funciona pero se oye peor, seguramente funciona a traves de la emulacion OSS de ALSA), por la libesd-alsa0. Tambien instalo el paquete alsaplayer-esd para que alsaplayer (el player que usa somad) pueda mandar sonido a esd. Mas tarde compilo e instalo la ultima version de esound que hay en debian 0.2.36-3, para intentar arreglar algunos problemillas, pero... Las aplicaciones para que utilicen esound o hay que configurarlas internamente, o arrancarlas con el wrapper esddsp. Las aplicaciones que he podido configurar son xmms (Menu ->Aukerak/Hobespenak -> Irteerako plugina= esound), alsaplayer (instalando alsaplayer-esd, y cambiando el output del player con '-o esound' (en /etc/somad/somad.cfg para que lo utilice somad). La que tengo que arrancarla con esddsp es glurp+mpd, que he puesto en el script que los arranca (/usr/local/bin/glurp-start) 'esddsp mpd'. Los problemas que esto da: - Tanto Mixxx, como Audacity (que solo esta en el Auxiliar) arrancados como 'esddsp audacity&' luego se oyen muy lento el sonido. Pruebo a ver si cambia el comportamiento pasando de la libesd-alsa a la libesd (de oss) pero ambos programas tienen el mismo comportamiento con ambas. Esto podria tener algo que ver con el harware, porque en mi ordenata no pasa a veces, pero despues de alguna prueba empieza a pasar siempre. Pruebo, para arreglarlo, a compilar la ultima version de esound que hay en Debian (0.2.36-3), pero los problemas continuan (tanto en el Server como en el Aux). La unica solucion que he encontrado es dejar a estos programas que no usen esound :-/ (audacity y mixxx). De esta manera los programas estan configurados para que utilicen: - Esound (se pueden arrancar a la vez varios y se mezcla su sonido): * Somad+alsaplayer * alsaplayer-gtk (solo en Auxiliar) * Xmms * Glurp+mpd - Acceso directo a la tarjeta de sonido (no Esound, hay que apagar antes cualquiera de los anteriores y ademas esperar 2 segundos antes de arrancar estos): * Mixxx * Audacity (solo esta en el Auxiliar). Asi que modifico la info en la ayuda de Garraxi, para indicar que no es necesario apagar una aplicacion de sonido para iniciar las otras, excepto en el caso de Mixxx. Dejo (por si acaso) comentado lo de parar una aplicacion para arrancar la otra. - Si tengo arrancado somad (utilizando esound) y arranco otra aplicacion que tambien lo usa (Xmms o Glurp+mpd) funciona bien (se oyen las dos). Pero si paro Somad un rato y despues intento volver a arrancarlo sin haber apagado la otra, Somad no arranca, da el siguiente error: [22 Tue 21:49:45] Binding error. Somad solo arranca despues de apagar la otra aplicacion y cuando se ha quitado el esd arrancado (que se apaga a los 2 segundos segun he puesto en la config). - Somad/alsaplayer sacan el siguiente output siempre: [22 Tue 20:39:32] Play: /home/garraxi/Biltegi/Musica/NOVEDADES/... ESD: rate fixed at 44100Hz ESD: fragments fixed at 256/256, stereo He intentado quitarlo con diferentes configuraciones, pero no hay forma. No da otros problema, solo que da mala pinta al Somad. Asi que he añadido otra capa de complegidad mas. Por ello, hago un seguimiento varios dias para comprobar que Somad se oye bien con esound por medio. Esto porque en algunas pruebas, parecia como si con esound el sonido se entrecortaba de vez en cuando. CALIDAD SONIDO: Probando el ripperX y la configuracion de seguridad de la musica compruebo que el rippeo con ripperX no se hace con las calidades que indica el manual del programa, que dice: Because Vorbis/Ogg uses variable bit rates, there is not a direct correla- tion between the bitrate selected for encoding and the rate used by oggenc. Instead, the bitrates in ripperX are mapped to the quality modes (1-6) sup- ported by oggenc. Bitrates 56, 64, 96 == mode 1, 112 and 128 == mode 2, 160 == mode 3 (the default), 192 == mode 4, 256 == mode 5, and 320 == mode 6. En vez de esto, si rippeas con bitrate 96, el archivo miradolo con ogginfo dice que tiene una 'Tasa de bits nominal: 96,000000 kb/s', y si lo haces con 128 sera de 128 kb/s. Ademas si encodeas un wav con oggenc y con diversas calidades q, la correlacion de estas q con el bitrate nominal es la siguiente: q0 = 64 kb/s q0,5 = 72 kb/s q1 = 80 kb/s q2 = 96 kb/s q3 = 112 kb/s q4 = 128 kb/s q5 = 160 kb/s q6 = 192 kb/s De esta manera, dejando la configuracion por defecto, que venia seleccionado el 128, estariamos encodeando a calidad de ogg q4 (posiblemente demasiada calidad). Asi que de momento dejo la configuracion de ripperX para que codifique a 112 kb/s que seria q3 (la por defecto de oggenc). Mirando unos mp3 que tengo del Gaztetxe unos estan encodeados a 96 kb/s y otros a 128 kb/s. Sin embargo, Gorka de Eztanda me decia que ellos encodean los mp3 a 192 (aunque no sabe que unidad es :-P), lo que seria una calidad q6 (posiblemente muy alta). HACER PRUEBAS DE AUDICION BUENAS CON UNA CANCION RIPPEADA A DIVERSAS CALIDADES Y ESTABLECER LA BUENA. Finalmente, en la version 2.7.0-2 de ripperx arreglan el problema en el manual y ahora dicen que la calidad elegida en la config de ripperx (en kb/s) se pasa al oggenc para que encodee con una calidad media de esa tasa de bits (con la opcion -b de oggenc), lo que probablemente hacia ripperx desde el principio. Por otra parte, en ripperX hay forma de escuchar la cancion antes de rippearla. Para ello es necesario instalar el paquete cdtool y despues en el dialogo de configuracion, en la pestaña players, cambiar (esta mal la linea de comandos): cdplay play % -> cdplay % cdplay stop -> cdstop Esto tambien se arregla en la version 2.7.0-2 (ambos arreglos por un bugreport que envie :-D). En cuanto a la grabacion de sonido para cuñas y programas, esta se realiza con flrec y sox. Para controlar la calidad de grabacion de ogg que ofrece sox la unica manera es modificar el codigo fuente antes de compilarlo (dado que por defecto, esta establecida a la calidad estandar de ogg, q3). Hay info de como hacerlo en el archivo programas-compilados.txt. Pruebo poniendo la calidad a q2 que son 90 kb/s nominales, y con q1, que son 70 kb/s. Pero 70 kb/s me parece una calidad demasiado baja, por lo que dejo instalada la version de 90 Kb/s. Mas tarde bajo una cuña en formato ogg de radiopwd, que que ellos mismos dicen que es "una versión en baja calidad" (supongo que para colgarla en la red), y veo que esta encodeada a 64 kb/s nominales, lo que equivale a una q=0. Para realizar la grabacion de cuñas y programas hago dos script en Xdialog que estan en /usr/local/bin (con los demas) y se llaman flrec-grabacunya.sh y flrec-grabaprograma.sh. en ambos se informa del espacio en disco donde se van a guardar los programas o las cuñas. De esta manera, si se pillara que hay poco espacio antes de ir a grabar, se podria parar y ver que pasa. Asi mismo, compruebo que, a la calidad de grabacion elegida (ver arriba), y en formato ogg, un programa de 1 hora ocupa aprox. 30 Mb, por lo que vemos que en el disco de programas (sdb1) hay espacio para 588 horas de grabacion. Visto la de programas que podemos guardar, quito la restriccion a que solo se guarde una copia del programa anterior, y ahora se guardan programas viejos con la fecha/hora de grabacion en el nombre del programa, en el dir .../Programas/nombreprograma/. Mas tarde me doy cuenta que al estar grabando programas directamente en el mismo dir desde donde Somad los re-emite (.../Programas/), puede pasar que cuando estemos grabando y emitiendo un programa en directo sin haber quitado el Somad, este empiece a reemitir lo que estamos grabando (porque ponemos que los programas se reemitan tambien en su horario de emision habitual, para que asi si el que hace el programa no viene, al menos se reemita un programa viejo). De esta manera, como la reemision habra empezado unos 5 minutos despues de empezar el programa, al terminar el programa en directo y volver a conectar somad on-air, se "reemitiran" los 5 ultimos minutos del programa recien acabado. Para evitarlo hago que los scripts de grabar programas y cuñas (este ultimo tambien porsiaca) graben primero en /tmp/ y despues, cuando se acabe de grabar lo pase a .../Programas/. Asi cuando se empiece la grabacion se quitara el programa anterior de .../Programas/ (se guardara en el dir de backup del programa) y cuando empiece a "reemitir" Somad el programa no encuentre nada y valla a la transmision de baja prioridad de musica, que estara ahi cuando se vuelva a poner Somad on-air. En cuanto a formatos de archivo de audio, utilizamos por defecto para todo el ogg, pero tambien tenemos soporte para encodear en mp3 (con Lame), aunque para que se pueda guardar como mp3 con sox habria que recompilarlo. Tambien instalo audio-convert para convertir de un formato de audio a otro. Compilado sox con soporte lame, se pueden grabar tambien programas y cuñas en formato mp3. Para ello modifico los scripts de grabacion, de manera que, aunque el archivo por defecto es un ogg, despues se puede cambiar el formato en la ventana de flrec, de forma que el script despues le pone la extension adecuada al formato real de archivo. Tambien compilo diferentes versiones de flrec (ver archivo programas-compilados.txt para saber como) de manera que para grabar cuñas solo permite los formatos ogg, mp3 y wav (este ultimo para editar sonido con audacity y no perder calidad en las conversiones de formatos), y para grabar programas solo ogg y mp3 (porque los programas son mas largos, ocupan mas en disco y grabarlos en wav puede ser demasiada ocupacion de disco). NORMALIZACION VOLUMEN ARCHIVOS DE SONIDO: Se comprueba que los archivos mp3 que nos pasa el Gaztetxe estan en general (no todos) a un volumen menor que los que estamos rippeando. Asi que conviene normalizar el volumen de esos archivos (y subirlo ligeramente en los que estan bajos). Hay como 3 enfoques posibles: 1. normalize-audio/gnormalice: descomprime el mp3 (u ogg) a wav, lo normaliza y lo vuelve a recomprimir. Por tanto es lento, necesita mucho espacio en disco y produce perdida de calidad en todos los casos. Tiene de bueno que el mismo sistema sirve para mp3 y ogg (cuando sea necesario). 2. normalize-audio, solo en el caso de mp3, tambien puede guardar en un tag el volumen de reproduccion al que quedaria normalizado, sin modificar el mp3, pero no todos los players lo soportan. (Para ogg eso se puede hacer tambien con VorbisGain). El problema clave es que en principio no hay ningun player que soporte este tag en los mp3 (en los ogg con vorbisgain creo que si). 3. mp3gain: normalizador solo para mp3, que no necesita decodear y encodear por lo que no hay perdida de calidad, no necesita tanto espacio libre en disco, y se supone que asi es mas rapido. Pero todo ello sin utilizar los id3 tags, por lo que sirve para cualquier player. Tiene el problema de que carece de opcion para recursividad. Finalmente para los archivos del Gaztetxe (que son todos mp3) utilizo este ultimo sistema. Para arreglar el que no pueda hacerlo recursivamente por todos los directorios utilizo find. En las primeras pruebas encuentro que al normalizar trata de bajar el volumen de casi todos los archivos (teniendo en cuenta que ya me parecia bajo de por si), por lo que decido aplicar un factor corrector que aumente la ganancia (ver archivo adjunto con info de todas las pruebas realizadas). Despues de muchas pruebas hago dos pasadas, una parcial para hacernos una idea de que factor -m aplicar. La hago con un comando tal que (en una linea, poner path adecuado): $ find /path/to/mp3 -type f -iname '*.mp3' -exec mp3gain -o '{}' \; | grep '/home/' | cut -f 1-3 -s > analisislog.txt Con lo que se genera un archivo de log con lineas del siguiente tipo (sin el encabezado que explica el significado de las columnas): File MP3 gain dB gain /path/to/archive1.mp3 -1 -1.400000 /path/to/archive2.mp3 -6 -9.350000 /path/to/archive3.mp3 -8 -11.990000 El valor 'MP3 gain' indica en un numero la ganancia que va a tener el archivo si se aplica la normalizacion (corregible con el valor -m), y 'dB gain' se la misma ganancia expresada en decibelios (y corregible con el valor -d). Asi se ve que el 3º ejemplo es el archivo que mas alto suena, porque va a perder mayor ganancia, mientras que el 1º suena bajo. Para hacer la normalizacion y que los archivos de mayor volumen apenas bajen su volumen (y se igualen algo a los que estamos rippeando) en el ejemplo se podria usar un valor -m 6, con lo que el archivo 2º no modificaria su volumen, el 1º subiria por un valor de "+5" y el 3º bajaria por "-2". O tambien se podria hacer con un valor -d 9.35, de forma que el 2º mp3 no variaria, el 1º subiria +7.95 dB y el 3º bajaria -2,64 dB. Pero hay que tener en cuenta que subidas importantes de la ganancia son peligrosas porque el sonido puede estropearse (que de hecho paso en la normalizacion realizada en unos pocos archivos), por lo que no es conveniente utilizar un valor muy alto de -m o -d. Tras el analisis previo de algunos directorios, y viendo que en la pagina de mp3gain para OS/2 (http://www.maazl.de/project/mp3/mp3gain.html) informan de que las default settings del programa son muy conservatibas y que puede aumentarse el valor -d por 2 dB, y que esto seria bueno para musica pop; se me ocurre utilizar un factor de aumento de ganancia -d 4. De esta manera, el comando que lanzo para normalizar todos los mp3 del Gaztetxe es (en una linea, poner el path adecuado): $ echo `date` > normalizlog.txt && find /path/to/mp3 -type f -iname '*.mp3' -exec mp3gain -r -d 4 -p -c '{}' \; >> normalizlog.txt && echo `date` >> normalizlog.txt Esto deja un archivo de log con la hora de inicio y de final del comando (en total fueron mas de 15 horas para los 15.000 archivos aproximados que habia), mas una referencia de la ganancia que aplica a cada archivo: Asi, como los archivos no se normalizan en ningun orden claro, para comprobar que se han normalizado todos los directorios se pueden ordenar las lineas del log donde esta el path, con el comando (en una linea): $ grep -v 'Applying' normalizlog.txt | grep -v 'No changes' | grep -v '...but tag' | sort > archivos-ordenados.txt Para ver cuanto se ha normalizado cada archivo y saber cuales se han cambiado mas su ganancia, para poder escucharlos y ver si estan bien o no, aplico el comando: $ grep 'Applying' normalizlog.txt | cut -c '29-' | sort -n > gain.txt Asi escucho los que mas han bajado su ganancia (que con bajadas de -8 y -7 no encuentro problemas de sonido) y tambien los que mas han subido. 2 archivos han subido por 12 y por 15, pero eran archivos mal grabados y los borro. Tambien hay algunos archivos (pocos) que han subido por 9, 8 y 6. Los que han subido por 9 su ganancia (2 archivos) se oyen un poco mal pero al tratar de desacer los cambios de mp3gain con la opcion -u, el resultado es peor, por lo que es mejor no hacerlo. Tambien se oyen un poco mal los que han subido por 8 (2 archivos) y algunos de los que han subido por 6 (pocos). Los demas parecen estar bien. * Otro enfoque a la normalizacion del volumen: Encuentro otro enfoque a la normalizacion del volumen de la musica, que es la aplicacion de un filtro en tiempo real al player para que normalice el volumen. El resultado es que las canciones que estan altas apenas modifican su volumen (el filtro impide que se produzca una distorsion por saturacion) pero las que estan bajas las sube el volumen hasta el nivel de (mas o menos) la emision normal. Este filtro existe en mplayer, que es el player que pasamos a utilizar. (lo he buscado en otros y no he encontrado nada parecido, quizas sox pueda utilizar algo parecido pero no lo he encontrado). Uso de mplayer para tocar archivos de sonido en consola: mplayer -ao esd,alsa, -msglevel cplayer=-1:decaudio=-1:lirc=-1:demux=-1:ao=-1 \ -af volnorm -novideo -noconsolecontrols -nojoystick -nolirc -nomouseinput \ "archivo de musica.[mp3|ogg]" -ao: indica el sistema de sonido a utilizar, se pueden poner una lista de ellos separados por comas, si se deja una coma al final intentara probar otros si los primeros fallan. Si no se pone busca el por defecto (posiblemente alsa). Usar para intentar que use esd. Tiene el problema que aumenta el output en consola, lo cual se puede corregir con -msglevel y el modulo adecuado (ao). -msglevel :=:...>: permite quitar mensajes de cada modulo, la lista de modulos se consige con 'mplayer -msglevel help'. El mejor output lo consigo con (manteniendo la linea que indica el progreso de la cancion): * /home/garraxi/.bash_profile: poner 'export MPLAYER_VERBOSE=-2' para que quite TODOS los mensajes en consola. * Poner en /etc/soma.cfg, donde la linea de comandos de mplayer '-msglevel avsync=5' para que muestre solo el progreso de la cancion. -af: para aplicar filtros de audio en tiempo real. Hay un filtro para normalizacion del volumen: -af volnorm[=method:target] Maximizes the volume without distorting the sound. Sets the used method. 1: Use a single sample to smooth the variations via the standard weighted mean over past samples (de- fault). 2: Use several samples to smooth the variations via the standard weighted mean over past samples. Sets the target amplitude as a fraction of the maximum for the sample type (default: 0.25). Puesto con las opciones por defecto (sin poner opciones del filtro), consigo que un archivo que es 10 Db mas bajo que otro con la misma cancion se oiga parecido de volumen (un poco mas bajo claro). Sin embargo el original que se oia fuerte, al principio parece que empieza mas fuerte con el filtro puesto, pero luego parece que se baja el solo para quedar mas o menos normal de manera que no distorsione. Ademas, el uso de la CPU no parece variar cuando ponemos el filtro y cuando no. Hago pruebas con diferentes valores para las opciones del filtro y finalmente encuentro que la opcion por defecto es la mas adecuada, dado que si se sube mas el target se puede llegar a distorsionar facilmente el volumen y el method apenas afecta nada. Probado tambien en la radio, las opciones por defecto parecen ser suficientes. Otro problema para utilizarlo con somad es que el mplayer que usa somad si se arranca sin indicar nada, permite la recepcion de eventos de teclado. Para desactivar esto pasar la opcion -noconsolecontrols. Tambien se pueden pasar las -nojoystick para que no haya soporte para joystick, -nolirc: para no soporte para dispositivos infrarojos y -nomouseinput para que no se haga caso al raton (porsiacaso). PROBLEMAS CON SOMA Con la Garraxi ya on-air, aparecen problemas con soma, que se queda colgado en determinados momentos sin haber pasado nada aparente segun el log. Esto lo achaco al compilar el programa haciendo strips a todo lo stripleable, asi que vuelvo a compilar el programa sin stripear nada (con lo que el paquete pasa de tener unos 3Mb a tener unos 8Mb). Con esto se paran los cuelgues... En el servidor, los scripts para pausar y releer somad dan problemas desde las primeras pruebas: - Pausar somad: El problema que daba es que aunque le dieras a pausar, si que pausaba somad, pero no dejaba de emitir sonido (hasta el final de la cancion no se paraba el sonido). Esto en principio podria ser porque en /etc/somad/palinsesto.cfg estaba configurado con el SoftStop activado (1). Puesto en desactivado (0) el problema continua. Esto es porque SoftStop no significa que espera a terminar la cancion para parar somad, sino que no ejecuta el comando enviado a somad hasta acabar la cancion (que no es lo mismo :-P). Ver man palinsesto.cfg. Para arreglarlo y que tras pausar somad se pare la cancion en curso, lo unico que se me ocurre es matar sox para que deje de emitir sonido (no encuentro modo de pausar sox). Para ello pongo un 'killall sox' en el script /usr/local/bin/pausar-somad.sh. Pero dejo el SoftStop desactivado. - Releer somad: Al dar al script de releer las configuraciones de Somad en muchas ocasiones este mataba al demonio al actuar (al enviarle el 2º o el 3º comando en general). Mirando la configuracion de soma, pruebo a ponerle en /etc/somad/soma.cfg el Background = true, pensando que podria tener algo que ver. Esto quizas mejore la situacion, pero hace que el demonio trabaje en background y no mande mensajes a stadout, por lo que la xterm en la que lo muestro desaparece y no se ve la cancion en que va y tal.Asi que pongo el Background = false. Una solucion que mejora el funcionamiento del script es poner unos sleep entre los comandos que manda el script /usr/local/bin/releer-somad.sh a somad (releer palinsesto, releer spot y releer directorios). De esta manera el "golpe" para soma de tres comandos seguidos no es tan grande. Pero esto no es mano de santo, asi que la otra historia que quito es la de presentar la evolucion de la cancion y tal en la ventana de somad. Para ello, en /etc/somad/soma.cfg pongo como opciones de linea de comando para 'play' (fronted de sox usado) el OptionsSong = "--silent". De esta manera parece que no vuelve a romperse?. Pruebo a ver si mejora usando music123 y va bien con el releer, pero da problemas de que no hay quien lo mate al pausar somad (killall music123 mata el script pero no el programa que realmente toca musica (ogg123 o mp321)). Probando alsaplayer-text, este parece que funciona bien en ambos casos. Ademas, para pausar somad no es necesario mandarle un killall porque el mismo se para cuando somad se pausa. Luego al reiniciar somad, alsaplayer se recupera pero con la nueva cancion que le manda somad. Ademas da output de como va la cancion que es igual tanto para ogg como para mp3 (con sox eran diferentes, para mp3 no daba cuanto duraba la cancion en total). Con releer alsaplayer da menos problemas sobre todo despues de cambiar el orden de los comandos mandados (pero dejo los sleep porsiacaso). Asi que cambio sox/play por alsaplayer-text como output para somad. El cambio en cuanto a memoria es: xvt+somad+alsaplayer = 1084 + 2092 + 3312 = 6488 Mb de memoria virtual xvt+somad+play+sox = 1084 + 2092 + 1324 + 1392 = 5829 Mb de memoria virtual Comprobadas todas las posibilidades con este sistema (arrancar somad, ripear canciones de un cd, releer la configuracion para encontrar las nuevas canciones ripeadas, pausar somad, grabar una "cuña2 mientras trabaja somad...) todo parece funcionar bien. El consumo de CPU cuando esta rippeando+somad+htop se acerca al 90% en los dos procesadores (pero nunca al 100% creo) pero la memoria no sube gran cosa (no swapea nada con esto). [Mas tarde cambio alsaplayer por mplayer, porque este ultimo ofrece un filtro para normalizacion del volumen en tiempo real (ver apartado de normalizacion del volumen de archivos). El consumo del sistema con mplayer queda (rxvt+somad+ mplayer): 1652 + 2824 + 4556 = 9032 Mb. Ademas, tampoco se rompe al releer los archivos (puesto esto como se explica a continuacion)]. Una vez puesto el server on-air, los problemas al releer la configuracion de somad continuan. Se suele romper somad cuando este lleva bastante tiempo andando sin parar y releemos su configuracion (tanto si releemos directorios+palinsesto+spot, como si solo releemos directorios+palinsesto). Por otra parte, estamos haciendo un poco el bobo, dado que al darle a releer la config de somad (que le da el usuario normal): se releen los directorios (para ver si se han añadido o quitado archivos lo cual puede hacer el user normal al rippear nuevos cd, por ejemplo), y tambien se releen el palinsesto.cfg y el spot.cfg (que solo lo pueden cambiar el Admin de la Emision). Asi que veo conveniente separar los dos aspectos, el releer directorios que lo pueda hacer el user normal desde el escritorio y lo demas que solo lo pueda hacer el Admin. Hago pruebas a ver como se comporta Somad al releer palinsesto.cfg y al releer los directorios (de momento no hago nada para el archivo spot.cfg, porque no lo utilizamos): * Añadiendo y quitando archivos con somad en marcha: Si añado archivos en el path de una parrilla que NO esta en marcha, cuando esta se pone en marcha somad encuentra los nuevos archivos sin necesidad de releer el directorio. Esto es porque al iniciar una nueva parrilla, somad lee el contenido de todos los directorios indicados en el path de la parrilla (recursivamente). Si añado archivos en el path de una parrilla que SI esta en marcha, estos archivos no se añaden por arte de magia, es necesario releer el directorio o releer palinsesto.cfg: - Si releer directorio: los nuevos archivos entran de inmediato, sin esperar a que acabe la cancion (relee los directorios mientras toca la cancion actual). -> Hay que usar este metodo. - Si releer palinsesto.cfg: los nuevos archivos entran cuando acaba la cancion actual, dado que entonces re-arranca la parrilla actual y entonces relee los directorios. En este caso si hay un jingle en la config de esa parrilla, este se vuelve a tocar. -> Mejor no usar este metodo. Entonces es necesario releer directorios solo cuando se añaden canciones al path de una parrilla en marcha (no en los demas casos, aunque seguramente no pase gran cosa si se hace). * Modificando parrillas con somad en marcha: Si añado nuevos "paths" a una parrilla que NO esta en marcha, cuando esta se pone en marcha somad NO mete los nuevos "paths". Esto es porque somad no se ha enterado de los cambios en palinsesto.cfg (hay que releerlo, y entonces se entera de los nuevos paths cuando acaba la cancion actual (y mete de nuevo el jingle, si existe)). Si añado nuevos "paths" a una parrilla que SI esta en marcha pasa exactamente lo mismo. Si añado una parrilla nueva dentro de palinsesto.cfg, somad tampoco se entera de ello hasta que no se le hace releerlo. Cuando se relee palinsesto.cfg, entonces: - Si la nueva parrilla ya deberia haber entrado, tras releer el palinsesto espera a que acabe la cancion actual y luego entra la nueva parrilla. - Si la nueva parrilla todavia no le toca entrar, tras releer el palinsesto espera a que acabe la cancion actual, relee los dirs de la parrilla actual y vuelve a meter el jingle de la parrilla actual (si existe). La nueva parrilla entrara cuando le toque. Entonces es necesario releer palinsesto.cfg cuando se añaden nuevos "paths" tanto a una parrilla en marcha, como a una parada, o cuando se añaden nuevas parrillas al palinsesto (tanto si tienen que entrar ya, como si tienen que entrar mas tarde). Osea, es necesario releer palinsesto.cfg SIEMPRE QUE se modifique el archivo palinsesto.cfg. De esta manera: - Pongo en escritorio y menu de Icewm del usuario normal acceso para que relea el directorio, y explico en ayuda que no es necesario hacerlo mas que cuando lo añadido va a la parrilla actual, aunque no pasaria gran cosa si se hace siempre (quizas sea mejor no hacerlo cuando somad esta emitiendo un programa muy largo, porque si Somad se "rompe", al rearrancarlo el programa empezaria de nuevo -> ponerlo en la ayuda y en el script). - Pongo en el script de Gestion de la Parrilla del Admin de la Emision, que cuando se acabe de editar el palinsesto con soma-editor, aparezca una ventana informando de que es importante decirle a somad que relea su palinsesto, y ofrezca al admin la posibilidad de hacerlo o no. Pero tengo que hacer dos versiones, una asi para el servidor y otra que no relea para el auxiliar, dado que desde el no se puede. Tambien añado en el server un script que solo relee el palinsesto, para el caso de que se haya editado la parrilla desde el auxiliar, que no sea necesario hacerlo todo de nuevo desde el server. GESTION PARRILLAS: El somax-editor (editor grafico parrillas) tras editar la parrilla la deja no leible por los demas users (necesario para somad, porque lo arranco como garraxi y la parrilla esta protegida por garraxi2). Para arreglarlo hago un script que tras editar la parrilla, chmodea el archivo a 644. El script esta en /usr/local/bin/somaxeditor-starter.sh y se paccede a el desde el panel del Administrador de la Emision. REPORTAR EL BUG A BAKUNIN?. Por otra parte, montar la parrilla con soma es un poco rollo... La primera prueba que hice fue poner una transmision de fondo general, con prioridad baja (desactivada), que era toda la musica que tenemos en random. Despues a determinadas horas se pondrian en marcha otras transmisiones de musica seleccionada (lasaia, del mundo...). Estas las ponia con prioridad activada para que pararan la transmision general y se pondrian en marcha. Pero esto no funciona debido a un problema de los players que no reportan adecuadamente que no encuentran la transmision con prioridad baja y no dan a Somad la posibilidad de pasar a la de baja (segun informa Bakunin). Los sintomas que daba somad asi configurado era que no activaba las transmisiones con prioridad activada y para que se activaran habia que pararlo y volver a iniciarlo durante el periodo en que estaba la transmision con prioridad activada. Finalmente he puesto para este rollo el siguiente esquema. Todas las transmisiones de musica (sea general o especial) iran sin prioridad. Pongo una transmision con toda la musica en random desde las 5:00 hasta las 21:00. Otra de "musicas del mundo" desde las 21:00 a las 23:00. Y otra de "musica lasaia" desde las 23:00 a las 5:00. Este sistema funciona, pero no se que pasara cuando sobre esto intente poner en marcha con prioridad activada la transmision de programas (la idea es que estos vallan con prioridad activada, de manera que si hay programa se ponga en marcha, y si no siga con la musica que esta con baja prioridad). (Tras la informacion de Bakunin, y mientras no resuelva el problema de las prioridades y los players, se deberan poner todas las transmisiones en la misma prioridad). Otros asuntos: - Es interesante poner en palinsesto.cfg a las transmisiones que tengan softstop=true. De esta manera la transmision no empieza hasta que acaba la cancion que esta sonando, cuando llega la hora. - Otra cosa interesante, en soma.cfg poner symlinks=true, de manera que siga los enlaces simbolicos. Esto puede servir para incrementar de manera sencilla la emision de una cuña, poniendo muchos enlaces simbolicos diferentes a una misma cuña. Pero no parece funcionar asi, de forma que para aumentar las veces que se emite una cuña la he tenido que copiar varias veces con el mismo nombre :-/. - Si se activa el flag de palinsesto.cfg spotcontroller, se pasa a un estado de control activo de spots y se empieza a usar la configuracion que hay en /etc/somad/spot.cfg (o lo que se ponga en soma.cfg). Si no se activa, entonces no hace caso a ese archivo, y utiliza el pathspot de palinsesto y el control de los spot se lleva directamente desde palinsesto (con el ratio cancion/spot). - El timecontinued para las transmisiones: - Si NO esta activado la transmision se repite todos los dias entre el dia que empieza y el que acaba en la franja horaria indicada. Ejemplo: xxxx-xx-xx Tue 21:00 xxxx-xx-xx Sat 00:00 Esta parrilla se repetiria entre el martes y el sabado todos los dias de 9 a 12 de la noche. - Si SI esta activado la transmision comienza en la fecha y hora indicada en start y acaba en la de stop. En el ejemplo anterior la transmision empezaria todos los martes a las 9 de lan oche y duraria varios dias hasta que acabaria todos los sabados a las 12 de la noche. Mas tarde hacemos una parrilla del tipo: lun | mart | mier | juev | vier | sab | dom 0:00 | | | | | | R | R | R | R | R | R | R+F 18:00 | | | | | | N | N | N | N | N | N | C 21:00 | | | | | | H | Pk | B+J | S+R | G+E+T | P+T | MM 0:00 | | | | | | R = Musica aleatoria (lun a vie 0:00-18:00, sab 3:00-18:00, dom 3:00-12:00) N = Novedades recibidas (lun a sab 18:00-21:00) H = Heavy (lun 21:00-0:00) Pk = Punk-Harcore (lun 21:00-0:00 y sab 21:00-0:00) B+J = Blues-soul (mier 21:00-23:00) + Jazz (mier 23:00-0:00) S+R = Musica Sakana (jue 21:00-22:00) + Rap-Hiphop (jue 22:00-0:00) G+E+T = Regae-ska (vie 21:00-23:00) + Experimental (vie 23:00-0:00) + Tecno-house (vie 0:00-3:00) P+T = Punk-Harcore (sab 21:00-0:00) + Tecno-house (sab 0:00-3:00) R+F = Musica aleatoria (dom 3:00-12:00) + Folk-vasco (dom 12:00-15:00) C = Chill-out (dom 15:00-20:00) MM = Musicas del mundo (dom 20:00-0:00) El problema que da esto con las parrillas es con el espacion de Punk-harcore que se repite martes y sabado y queria mantenerlo como una sola entrada en la parrilla para no tener que andar editando en dos entradas a la vez. Para ello, hago una transmision tal que asi: Punk-harcore mart-sab 0 xxxx-xx-xx Tue 21:00 xxxx-xx-xx Sat 00:00 0 0 Pero esto el problema que da es que no esta claro si es una transmision de martes 21:00-0:00 y sabado 21:00-0:00 o desde el martes hasta el sabado (todos los dias) de 21:00-0:00. En somax-editor da problemas porque aparece en la GUI (ademas de martes y sabado) esta transmision tambien los jueves y viernes. Asi, se comprueba que es el 2º caso, y que aunque el miercoles a las 9 no entra esta transmision (por la razon que sea, posiblemente porque le hace mas caso a alguna parrilla configurada antes para ese dia), si lo hace el jueves a las nueve, y parece que tambien lo haria el viernes (porque asi lo muestra somax-editor). Para arreglarlo, elimino de la parrilla el que el sabado entre punk, y lo sustituyo en el mismo horario por pop-rock (que no habia). He pedido a Bakunin la feature de que exista la posibilidad de parrillas solo los dos dias de start y stop (como no-timecontinued, pero solo el dia de start y el de stop). Dado el problema con la prioridad, para hacer la parrilla y que emita un programa si existe y si no que ponga musica, utilizo un sistema tal que asi: 1 xxxx-xx-xx Tue 21:00 xxxx-xx-xx Tue 21:01 0 1 /home/garraxi2/Biltegi/Programas/ejemploprograma.ogg De esta manera el programa "ejemploprograma" se emite los jueves a las 21:00 si el archivo esta en su sitio (y dura lo que dure el archivo). Si no esta, al cabo de un minuto empezaria la siguiente transmision, que seria musica para cubrir el hueco. Este sistema de meter un programa en la parrilla tiene un bug, en su interaccion con la parrilla anterior y siguiente. Asi, en el ejemplo de meter un programa a las 12:00 pero con la parilla anterior y la siguiente con el sofstop activado: xxxx-xx-xx Tue 0:00 xxxx-xx-xx Tue 12:00 NUSICA1 1 ---------------------------------------- xxxx-xx-xx Tue 12:00 xxxx-xx-xx Tue 12:01 PROGRAMA 1 ---------------------------------------- xxxx-xx-xx Tue 12:01 xxxx-xx-xx Tue 18:00 NUSICA2 1 En este caso, el programa de las 12:00 solo entrara si la cancion/programa de la parrilla anterior acaba antes de las 12:01 (puede acabar mas tarde, por el softstop). Si la transmision acaba mas tarde es como si ya se le habria pasado la oportunidad al programa y pasa a la parrilla siguiente de musica (la de las 12:01 que esta puesta asi solo por si el programa de las 12:00 no existe). Probadas soluciones con este esquema, una podria ser (si las parrillas anteriores y siguientes a la del programa de las 12:00 son de musica) el poner la parrilla del programa que empiece a las 12:00 y acabe a las 12:10. De esta manera, al haber 10 minutos de margen es mas facil que la cancion de la parrilla anterior acabe dentro de esos 10 minutos y pueda entrar el programa. Pero no es seguro. Ademas, si el programa no existe tendriamos casi 10 minutos de silencio antes de que empezaria la musica. La solucion mejor es poner la parrilla anterior a la entrada de los programas con el softstop desactivado (y la del programa no, para que la transmision dure todo lo que dura el programa): xxxx-xx-xx Tue 0:00 xxxx-xx-xx Tue 12:00 NUSICA1 0 ---------------------------------------- xxxx-xx-xx Tue 12:00 xxxx-xx-xx Tue 12:01 PROGRAMA 1 ---------------------------------------- xxxx-xx-xx Tue 12:01 xxxx-xx-xx Tue 18:00 NUSICA2 1 De esta manera, a las 12:00 la parrilla anterior se pararia por narices este donde este y entraria el programa de las 12:00 si existe. En el caso de que el programa no exista, al cabo de un minuto exacto entraria musica. Asi que he planteado que todos los dias de entre semana se reemitan los programas grabados a las 12:00, para lo que he modificado la parrilla puesta mas arriba y la he dejado: lun | mart | mier | juev | vier | 0:00 | | | | | R1 | R1 | R1 | R1 | R1 | 12:00 | | | | | P | P | P | P | P | 12:01 | | | | | R2 | R2 | R2 | R2 | R2 | 18:00 | | | | | Donde "P" son los programas reemitidos y "R" es la musica aleatoria, que esta en dos bloques, R1 de 0:00 a 12:00 y R2 de 12:01 a 18:00. De esta manera, los dias que no haya puesto ninguna reemision de programas habra siempre un silencio de 1 minuto a esa hora, lo mismo que los dias que no exista programa para reemitir. Para evitar estos silencios hago otras pruebas, sin resultados: xxxx-xx-xx Tue 0:00 xxxx-xx-xx Tue 12:00 0 ---------------------------------------- xxxx-xx-xx Tue 12:00 xxxx-xx-xx Tue 12:01 1 ---------------------------------------- xxxx-xx-xx Tue 12:00 xxxx-xx-xx Tue 18:00 1 En este caso la musica del 2º bloque intentaria entrar a la vez que el programa (y en teoria no habria silencio si este no esta). Sin embargo la prueba dice que si esta el programa entra, y si no esta se espera a que termine su transmision de 1 minuto y la musica sigue entrando a las 12:01. xxxx-xx-xx Tue 0:00 xxxx-xx-xx Tue 12:00 0 ---------------------------------------- xxxx-xx-xx Tue 12:00 xxxx-xx-xx Tue 12:00 1 ---------------------------------------- xxxx-xx-xx Tue 12:00 xxxx-xx-xx Tue 18:00 1 En este caso la parrilla del programa no dura nada (empieza y acaba a la misma hora, la misma hora a la que empieza la siguiente transmision). Esto somad no lo entiende y produce que el programa empiece aunque no sea su hora, siempre que somad arranca. Otro problema aparte es que en una transmision de 1 minuto para un programa, no se puede poner un jingle que dure mas de 1 minuto, sino el programa ya no entra porque se ha pasado el tiempo de la transmision. Lo mismo pasa si se pone una sola transmision para varios programas, que si son 2 la transmision tiene que durar exactamente lo que dure el 1º programa mas unos segundos mas, demanera que de tiempo a acabar el 1º programa y todavia estemos a tiempo para que entre el segundo. GESTION DE ARCHIVOS DE PROGRAMAS DE RADIO ANTIGUOS: El problema era ¿que pasa si no se graba un nuevo programa la siguiente semana?. Pues que se volveria a reemitir el mismo programa. Para evitar tener que andar pendiente de que los programas no se reemitan demasiadas veces, ideo un sistema script cron que permita que: 1. El archivo de programa no este en el dir Programas mas de X dias (si no se hace programa nuevo), para que no se repita mas de X veces. Ejemplo con 10 dias se repite 2 semanas seguidas. Con 7 dias se pone solo 1 semana (la semana en que se graba, el dia que se hace en directo y el de su reemision, por ejemplo). 2. Cuando se valla a quitar automaticamente un programa, que se sustituya por otro (de forma aleatoria por ejemplo) de los guardados en backup (antiguos), para que siempre haya programa para reemitir. Hay que tener en cuenta el efecto sube-baja. Esto se produciria al estar moviendo un archivo viejo (de mas de X dias) con lo que cada noche, cron lo volveria a backupear / lo borraria y pondria uno nuevo en su lugar. Esto pasa con mv porque no cambia la fecha del archivo, pero no con cp (opciones por defecto) porque pone al archivo copiado la fecha actual. Tener en cuenta tambien que cuando se valla a backupear un programa nuevo, y que despues se busque uno aleatorio para ponerlo en su lugar, hacer la busqueda antes que el backupeo para que el recien backupeado no entre en el listado a buscar (de manera aleatoria) y que no se pueda repetir el mismo programa por casualidad. - Metodos: copiando el programa y moviendolo: COPIANDO el programa desde el dir de backup al de Programas: Ventajas: * Es mas seguro, no se anda con el archivo original de aqui para alla. * Es mas seguro porque implementa un test de archivos duplicados para no guardar 2 copias de lo mismo. Entonces si alguien copia el programa a mano, lo detecta y lo borra. Si alguien mueve a mano tambien lo detecta y lo backupea. * El sistema cron actual de mantenimiento de programas sigue parecido, solo hay que implementar en él los scripts necesarios. * El efecto sube-baja se evita simplemente cambiando la fecha del archivo (mtime). Esto no interfiere con el mantenimiento de backups con la fecha en el nombre del archivo porque donde lo hacemos es en una copia que luego borraremos. Inconvenientes: * Los scripts a implementar son mas complicados que en para mover archivos. * El test de archivos duplicados hay que implementarlo tambien en el script de grabar programas. * El sistema va a borrar archivos (aunque solo copias de programas) asi que puede equivocarse y borrar algun programa nuevo. Implementar un sistema de logeo de lo que borra para poder detectar fallos del script. MOVIENDO el programa desde el dir de backup al de Programas: Ventajas: * El sistema de scripts es mucho mas sencillo porque no necesita del test de archivos duplicados (ni en mantenprogramas, ni en grabaprogramas). Solo hay que implementar en mantenprogramas el sistema para colocar un programa de backup para reemitir cuando se quite el programa ya reemitido. * No borra ningun archivo, por lo que no hay peligro de que se equivoque. Inconvenientes: * Es mas inseguro porque mueve archivos originales. * Si alguien copia el programa viejo a mano para reemitirlo, el sistema lo vuelve a backupear, gastando espacio en disco inutilmente. * Para evitar el efecto sube-baja habria que implementar tareas cron especificas para cada programa (editables con gcrontab, por ejemplo) lo cual es dificil de administrar; o cambiando la fecha del archivo, pero esto hace que al volver a backupearlo la fecha que ponemos en el nombre del archivo no sea la de verdad. Para evitar esto ultimo se deberian utilizar diferentes fechas para el control del archivo con cron y para el nombre del archivo, lo que complica aun mas el asunto. SOLUCION ELEGIDA: COPIANDO. Para ello se implementa: * En script cron mantenprogramas (en /etc/cron.daily/): 1º test de archivos duplicados antes de backupear archivo 2º sistema de backup de archivos a dir de backup y nombre con fecha de archivo 3º sistema de sustitucion aleatoria de programas a reemitir * En script flrec-grabaprograma.sh (en /usr/local/bin): 1º test de archivos duplicados antes de backupear archivo 2º sistema de backup de archivos a dir de backup y nombre con fecha de archivo El script mueve a directorio de backup los archivos de programas que sean mas viejos que 10 dias (de manera que no se repitan mas de 2 veces). Ademas repone archivos de programa aleatorios desde el dir de backup, manteniendolos 7 dias, y chequea que no se guarden duplicados de ellos. La reposicion de programas solo se realiza si en el dir de backup hay 3 o mas archivos de programa. Todos los movimientos de archivos se logean en /var/log/mantenprogramas.log. Se pueden excluir programas de la reposicion (ejemp: una "agenda conciertos") poniendo su nombre exacto (cada uno en una linea) en el archivo: /home/garraxi/.programas-radio/reponprograma_excludes.txt PROBLEMAS EN LA INTERACCION ENTRE SOMAD Y SOMAX: Con las versiones de somad 2.2-2.4 y las de somax 1.1-1.3 (al menos) cuando intento conectar el somax a un somad arrancado, este ultimo se cae en pocos segundos y somax da "problema de conexion" o "problema de SSL" (segun). Haciendo pruebas detecto que esto ocurre porque tenemos el somad arrancado sin usar SSL, y que si arrancamos somad usando ssl y despues somax (tambien usandolo claro) el problema mejora (pero no desaparece). Probando ademas a utilizar un somad sin soporte para ssl (desactivado en la compilacion) y un somax compilado contra ese somax, los resultados son los mismos. Asi que de momento tenemos que arrancar somad con ssl activado (en /etc/somad/soma.cfg, activando ssl y poniendo las rutas al certificado y la private key; si se quiere poder usar somax. Hecho esto, es necesario cambiar todos los scripts en los que utilicemos somaclient, dado que a este ultimo hay que pasarle la opcion -ssl si se quiere que funcione (si no somaclient dice que somad esta trabajando con ssl y que se active esa opcion). De esta manera he modificado todos los scripts que afectan a somad (garraxi2-gestionparrilla-server.sh, garraxi2-releerpalinsesto.sh, parar-somad.sh, pausar-somad.sh y releer-somad.sh). De esta manera, si alguna otra vez vuelvo a no usar la encriptacion por ssl, habra que modificar otra vez todos esos scripts, y quitarles la opcion -ssl. Por otra parte, en el bugtraking de somad (http://bugs.ippolita.net/) esta abierto un bug con este problema, el nº soma 0000013. OTROS PROGRAMAS INSTALADOS: Otros paquetes nuevos (o actualizados) instalados: - manpages-es - docbasica-es - flrec - scripts para grabar cuñas y programas con flrec (sustituyendo a somaplayer). - gtkedit v.1.0 (internacionalizado) - pinfo - mrxvt v.0.5 (para la consola basica) - audacity (la que venia en Sarge, decidido por fin como editor de sonido). - dwww-rebuild (instalado en /sbin, para que solo lo pueda utilizar el root, dado que es un script que llama a programas que solo puede utilizar el root). Pero no es necesario porque en garraxi tenemos instalado y activado cron (en el server) y anacron (en el aux) y el rebuild de dwww se realiza periodicamente. - dwww 1.10.0 (de Sid, bastantes mejoras sobre el de la Sarge). - htop 0.6.1 (trae soporte para medir varias CPUs). - soma 2.2 (y somax 1.1, pero este es mas viejo). - Xdialog 2.2.1 (arregla bug en ventana elegir directorio). Luego v. 2.3.1 - Lame para poder encodear mp3 si es necesario (probado con ripperX con exito). - RipperX 2.7.0 (tiene soporte para tags id3v2) - Mixxx: un programa para mezclar musica en plan D.J. (como el BPM Studio de windows). Pongo icono en escritorio y en menu, y un poco de ayuda. - Rxvt: una terminal ligera, paquete debian oficial de Sarge. La usamos para presentar la pantalla con el output de somad, tras los problemas de corrupcion de letras que daba xvt. - Audio-convert: un script en Zenity para convertir de un formato de audio a otro. Puesto tb. mime-tipe en endeavour para seleccionar archivos. - Rox-filer: para iconos de escritorio y tambien manejo de archivos del tipo ventana de cada carpeta. Sustituye a Xtdesk en lo de los iconos (ver arriba). - gmusicbrowser: para poner musica a traves de una lista de reproduccion. Sustituye a Glurp+mpd que tienen varios problemas: va mal para reordenar las canciones en la lista de reproduccion, dado que la primera no deja moverla y si se mueve da errores, le cuesta arrancar a tocar una cancion, ademas es necesario actualizar la base de datos para añadir las nuevas canciones (con gmusicbrowser tambien hay que releer las canciones cuando se han introducido nuevas). Despues de instalar algunos de estos programas hay que arrancarlos como usuario garraxi. Asi crean ficheros y directorios de config en home/garraxi. Despues dejarlos completamente configurados y proteger los ficheros de config (los que se puedan y no den problemas con el programa) asignandolos al usuario garraxi2. AYUDA DE GARRAXI: Tambien actualizo la ayuda de Garraxi (/home/garraxi/.ayuda/ayudagarraxi*.html) para reflejar el uso de Flrec como grabador, añadir enlaces a las ayudas instaladas en el ordenata de los programas que se citan y meter algo mas de txapa sobre las ayudas del sistema Debian y tal :-P. Tambien otro capitulo de ayuda para el uso de Endeavour, la gestion de archivos en Garraxi y el tema de la proteccion de los archivos con garraxi2. Tambien todo un capitulo sobre el nuevo sistema de gestion de tareas del Administrador de la Emision (garraxi2). Incluyo referencia a esta ayuda en el menu de ayuda de Dwww escribiendo el fichero /usr/share/doc-base/ayuda-garraxi. Para que despues realmente salga la ayuda a traves de dwww hay que añadir el path /home/garraxi/.ayuda a los permitidos en la configuracion de dwww (en /etc/dwww/dwww.conf) a traves de la variable DWWW_DOCPATH (ver man dwww.conf(5)). De esta manera, al buscar garraxi en dwww (secciones "menu" y "registered docs") aparece el enlace a la ayuda. PROBLEMAS COMUNES Y SUS SOLUCIONES: - En ocasiones somad deja de emitir y solo muestra en su ventana mensajes repetidos del tipo: ERROR: bad data stream! (samplerate: 44100 != 11025, frame 153006) Esto es por un problema en el archivo que estaba tocando que no esta bien grabado. Para saber que archivo que se estaba tocando ir al log de somad con Xlogmaster: sera el ultimo que estaba tocando. Despues probar a escucharlo en una consola (desde el ordenata Auxiliar) con el comando: alsaplayer -i text -o alsa --nosave 'archivo_sonido_txungo.mp3/ogg' que es el mismo comando que utilizamos con Somad. Es muy facil que el error este hacia la mitad o el final del archivo, por lo que hay que oirlo entero. Si no va bien el archivo, se puede intentar recuperarlo con Audacity, o mejor borrarlo. ========================================== SEGURIDAD: - Despues de instalar cada nuevo programa, probarlo, configurarlo adecadamente y ver si se puede proteger la configuracion asignando el fichero de configuracion al usuario garraxi2. De esta manera, la unica pega es que el usuario puede modificar la configuracion mientras tiene arrancado el programa (ejemp. cambiar el dispositivo de grabacion en flrec y que ya no le grabe), pero esto se arregla quitando el programa y volviendolo a arrancar que saca las settings por defecto, porque el cambio que hace no se puede guardar. PROTEGER LA MUSICA Y CUÑAS: Se me ocurren 3 formas de proteger la musica y cuñas de manera que no se puedan borrar accidentalmente: * Que los dir de musica y cuñas, asi como los propios archivos sean de solo lectura (configuracion de archivos r--r--r--, configuracion de dir r-xr-xr-x). De esta manera, si los dir son de solo lectura, no se pueden borrar los archivos que estan en ellos, pero tampoco se pueden guardar directamente nada en ellos. De esta manera habria que rippear CD o grabar cuñas en un dir temporal y despues que un administrador moviera los archivos a los directorios adecuados. * Que los dir y los archivos de musica y cuñas pertenezcan al usuario garraxi2 por defecto desde el principio. Pasa igual que antes, no se puede rippear CD's ni se pueden grabar cuñas directamente en estos directorios y hay que moverlos a mano por un administrador con permisos. La solucion para poder rippear CD's y grabar cuñas podria venir a traves de scripts con sudo (permite correr comandos como si fueras otro usuario o como si fueras root, segun la config) que hiciera que se estuviera grabando realmente con garraxi2. Pero esto el problema que tiene es que si algun archivo no queda bien, el user no lo puede borrar (ya que pertenece a garraxi2) y queda a disposicion de Soma para ser emitido :-/. * Solucion intermedia, los directorios raiz de la musica (/home/garraxi/Biltegi/Musica) y las cuñas (/home/garraxi/Biltegi/Kunyas) pertenecen a garraxi y la musica y las cuñas (archivos y tb. subdirs) se van pasando a pertenecer a garraxi2 segun se van grabando, cuando un administrador tenga tiempo. De esta manera cualquier usuario puede grabar cuñas y CD's en los dirs adecuados, estando los archivos inmediatamente a disposicion de Soma, permitiendo tambien que el user pueda borrar los archivos que no le hayan quedado bien. La seguridad viene un poco despues, cuando el admin revisa lo que hay en esos directorios y protege todos los archivos que valgan (y subdirs) pasandolos a garraxi2. Esto es para musica y cuñas, pero no para programas, porque tenemos (su)puesto que los archivos de los programas duran 1 semana?, hasta que se hace el siguiente programa que "machaca" el anterior (se guarda copia de seguridad solo del de la semana? anterior). De esta manera no es necesario proteger demasiado los programas. Para proteger la musica/cuñas hay que ponerse como root (no vale ponerse como garraxi2), por lo que solo lo puede hacer el admin general. Despues ir al directorio adecuado (ejemplo /home/garraxi/Biltegi/Musica para proteger toda la musica), y correr en una consola el comando: chown -R -v garraxi2:garraxi2 * -R: recursivamente en subdirectorios -v: verboso, da info sobre lo que hace garraxi2:garraxi2: cambia a usuario y grupo garraxi2 *: todos los archivos y subdirectorios Esto cambia el propietario de todos los ficheros y subdirectorios del directorio donde estamos (en el ejemplo /home/garraxi/Biltegi/Musica, el dir raiz de la musica). Si algun fichero o subdirectorio ya es propiedad de garraxi2, lo pasa por alto. El problema vendria ahora si se quiere rippear una cancion (por ejemplo) y ponerla en un subdir de musica determinado (por ejemplo rippear canciones de Muguruza y tratar de meterlas en un dir de este autor). Esto no se podria directamente, habria que rippearlas en un dir nuevo y luego en todo caso moverlas al que queriamos (esto lo debe de hacer el root). Sin embargo, con ripperX es dificil poner exactamente el mismo dir, por lo que es dificil que esto pase. Doy sudo a garraxi2 para hacer esto con: sudo chown -R -v garraxi2:garraxi2 * Hago tambien un script en xdialog que permite elegir el dir que se va a proteger y da el output del comando anterior. Lo integro en el script de tareas del admin de la emision, ver mas adelante. Otro problema detectado es que al copiar los mp3 de un cd al directorio de musica, y luego protegerlos con el script, los directorios que se copian desde el cd pasan a ser solo "abribles" por garraxi2, con lo que no se puede usar la musica (pasan a tener permisos rwx------). El problema parece que solo afecta a endeavour2 y solo cuando copia archivos/directorios que no pertenecen al usuario que tiene arrancado endeavour2, pero no cuando los mueve. Cuando los copia, deja los dir en el dir de destino con los permisos rwx----- y user garraxi cuando tendria que ser r-xr-xr-x y user garraxi como hacen los demas programas. Asi que se trata de un bug del programa, ya que tanto emelfm como el comando cp los copia bien. (El bug esta ya corregido) Para "solucionarlo" y ademas para conseguir un poco que los permisos de los archivos de musica sean homogeneos en todos ellos, independientemente de su origen (los archivos que vienen desde dispositivos fat como memorias usb, suelen venir como ejecutables), añado al script de proteger la musica la funcion de poner permisos. El unico problema que deja esto es que si los archivos ya estaban como ejecutables, el script lo mantiene, dado que utilizo la opcion X de chmod, que esta diseñada para dar permisos de ejecucion a los directorios aunque no los tengan y de mantener los permisos de ejecucion de los archivos que los tuvieran (no de los que no los tienen). Otro problema que detecto en el script es que si garraxi2 desea mover un dir protegido (perteneciente a garraxi2) a un dir que pertenece a garraxi (como por ejemplo el raiz de la Musica) el sistema no te deja porque no tienes permisos para hacerlo. La solucion pasa por poner en el script que los permisos de todos los archivos y directorios que se van a proteger sean rw-rw-r-- (ficheros) y rwxrwxr-x (directorios). De esta manera en los dir pueden escribir tanto el user al que pertenece, como los que estan en su grupo. Asi, añadiendo garraxi2 al grupo garraxi (adduser garraxi2 garraxi), el admin garraxi2 ya puede mover archivos a directorios que pertenezcan a garraxi. Otra idea tambien es que los dir y archivos que crea nuevos el user garraxi tengan esos permisos desde el principio. Para ello editar ~/.bash_profile y poner el umask como 0002. SCRIPT XDIALOG TAREAS DEL ADMIN DE LA EMISION: Hago un script en xdialog como panel de control de las tareas que puede que realizar el Admin de la Emision (garraxi2). Primero pide la contraseña de garraxi2 a traves de gksu, con la orden (puesta en el menu de Icewm: gksu --user garraxi2 --message "Mete la contrasenya del Administrador de la Emision" garraxi2-tareas.sh Despues va a una ventana con todas las posibles tareas que se me ocurren: - Proteger Musica/Kunyas (script del apartado anterior) - Editar lista de programas a grabar (con script en xdialog y fichero de "configuracion de programas de radio") - Gestión de la Parrilla (somax-editor) - Terminal de texto (mrxvt) - Cambiar fecha/hora ordenata (con script xdialog pillado de sources xdialog). - ... Todas estas tareas son arrancadas con el user garraxi2 gracias a gksu. Tambien cambio el script /usr/local/bin/flrec-grabaprograma.sh para que utilice para mostrar los programas que se pueden grabar, el contenido del fichero /home/garraxi/.programas-radio/programas.txt, que hago pertenecer a garraxi2 (fichero y dir) por seguridad. De esta manera, para cambiar o añadir programas a esa lista simplemente vale con cambiar ese archivo. Hago un script en xdialog que permite cambiar ese archivo como si fuera un editor de textos y ademas da instrucciones de como "formatear" el archivo (cada nombre de programa en una linea separada, nombres de programas sin espacios dentro del nombre y que sea exactamente igual al puesto en la configuracion de la parrilla de somad). Tambien hace copia de seguridad del archivo anterior (porsia). El scrit para actualizar la fecha/hora esta pillado de las fuentes de xdialog y lo tengo probado en mi ordenata bastante tiempo por lo que no da muchos problemas. Esta en ingles. No es necesario utilizarlo en el server para los cambios horarios invierno-verano, dado que el server, si esta arrancado en el momento del cambio, lo hace solo. Si es necesario en el auxiliar, porque no suele estar arrancado a esa hora. Pongo esto en la ayuda. No pongo (de momento) el editor de la configuracion de somad (somax-config) porque no le encuentro utilidad (la config no es necesario tocarla apenas, y cuando si, mejor la toco yo). Tampoco incluyo de momento somax (GUI que se conecta a un somad arrancado para gestionarlo) porque en las pruebas rapidas me ha fallado y ademas no le encuentro mucha utilidad (gran parte de su utilidad la tengo cubierta con los scripts para arrancar somad, releer somad...). Tambien pongo somax-editor para gestionar la parrilla, con un scritp para evitar el problema de que deja la parrilla no leible (ver arriba). Hago una completa pagina de ayuda con explicacion de como hacer y actualizar parrillas, asi de como solucionar el problema de los directorios con acentos y tal (con endeavour2 en modo admin y gtkedit para editar a mano /etc/somad/palinsesto.cfg). Tambien se añade a las tareas del admin de la emision la posibilidad de apagar/reiniciar el ordenata, la de gestionar archivos con endeavourII en modo admin de la emision y la de editar los tags de los archivos de sonido protegidos como garraxi2 (con easytag en modo admin de emision). POSIBLE AGUJERO DE SEGURIDAD CON VORBISCOMENT Detecto un posible bug en la addicion de comentarios a un ogg de solo lectura o de otro usuario, que produce que se cambie de usuario y se vuelva de lectura y escritura. Esto ocurre con easytag y otros programas de cambiar tags, y tambien con vorbiscoment. Sin embargo no pasa con los mp3, solo con los ogg. Informo a Debian a traves del BTS y me comentan que en realidad es un comportamiento "normal", dado que lo que hace vorbiscoment (y seguramente easytag y todos los programas de cambiar los tags) es abrir una copia del archivo que se va a cambiar los tags, editar en esa copia los tags, cerrar la copia y renombrar la copia con el nombre del archivo original, con lo que se machaca el original y se queda la copia, pero con el user que ha modificado el archivo. Tambien comento a Debian que no me parece muy correcto el sistema y que se deberia evitar este comportamiento, a lo que un desarrollador de Debian me dice que el tambien lo cree asi y que se deberia cambiar le programa o al menos la documentacion del mismo para informar del problema. Pero es necesario que sea el mantenedor del programa el que le parezca bien el asunto y haga algo... Sin enbargo el problema no sera tan grande en la Garraxi, porque esto solo afecta a archivos ogg de otro usuario (garraxi2) que esten en directorios que pertenezcan al usuario que edita los tags (garraxi), tal y como informan los de Debian. De este modo, todos los ogg's que esten en directorios protegidos (pasados a pertenecer el directorio tambien a garraxi2) no se pueden editar. Asi, solo los ogg's que permanezcan en el directorio raiz de la musica (~/Biltegi/Musica) podrian ser editados de esta manera, no el resto si estan protegidos. COPIA DE SEGURIDAD DE LA PARRILLA: Pongo una tarea diaria de cron (añadiendo el archivo /etc/cron.daily/copiaparrilla) para conseguir que se haga una copia de seguridad de /etc/somad/palinsesto.cfg (si se ha modificado) en /home/garraxi2/cosas-viejas y que ademas que se guarden diferentes versiones del archivo. El codigo (tomado de /etc/cron.daily/standard y adaptado), es: # 1. Compara si copia de backup de palinsesto.cfg y original han variado. Si SI: # 2. Hace una copia del fichero original en el dir de backup # 3. Rota las copias de backup, manteniendo hasta 7 versiones (-c 7) if ! cmp -s /home/garraxi2/cosas-viejas/palinsesto.cfg.0 /etc/somad/palinsesto.cfg ; then cp -p /etc/somad/palinsesto.cfg /home/garraxi2/cosas-viejas/palinsesto.cfg savelog -c 7 /home/garraxi2/cosas-viejas/palinsesto.cfg >/dev/null fi VOLUMENES DE LAS TARJETAS DE SONIDO Y MIXERS: Veo que es importante que no se toque mucho los volumenes a los que emitimos desde el ordenata y al que se graba en el. Por ello quito todos los accesos a los mixers para que no se puedan tocar mas que por el Admin de la emision. Para ello cojo los ficheros /usr/X11R6/bin/xmixer (del paquete mctools-lite) y los /usr/bin/ aumix, xaumix, mute (del paquete aumix-gtk) y /usr/bin/alsamixer (del paquete alsa-utils) y los pongo con usuario garraxi2 y grupo root, y con permisos 754, osea: rwxr-xr-- garraxi2:root. Esto permite que lo ejecute garraxi2 y tambien root, pero no garraxi. Instalo aumix-gtk como mixer por defecto (arrancable desde el panel del Admin de la Emision). Lo elijo porque es el unico que encuentro que informe de los volumenes tambien con numeros, para que sea mas facil dar una referencia. Dejo tambien mctools-lite (xmixer y xcdplay) de manera que se utilice xcdplay para tocar cds y tambien este por ahi xmixer pero lo "protejo" para que solo lo pueda utilizar los admins, como aumix-gtk. Lo mismo hago con alsamixer. Hago un script xdialog para elegir a que mixer se quiere acceder (con info de que en la ayuda estan las imagenes con la default-setings de cada mixer). Configuro bien los volumenes de ambas tarjetas, hago screenshots de esos volumenes con aumix y los pongo en la ayuda, para poder volver a recuperar los volumenes buenos si pasa algo. Ademas para que la ventana de aumix salga a un tamaño bonito, hay que poner en ~/.icewm/winoptions: 'aumix.Aumix.geometry: 600x200' Realizo pruebas de grabacion de musica y voz para conseguir el volumen ideal de la tarjeta para grabar. Las pruebas las hago siempre con el volumen de la musica llegando al naranja en el medidor de la mesa de mezclas de la radio, y el volumen de la voz llegando al rojo: - Volumen del Mic en aumix a 82: la grabacion esta a un volumen mas bajo que el sonido emitido (no graba a buen volumen). - Volumen del Mic en aumix a 86-87: la grabacion esta aprox. al mismo volumen que el sonido emitido (quizas un poco mas bajo). Probando tambien a grabar sonido emitido saturando el rojo de la mesa de mezclas, tambien se graba bien (dentro de lo que cabe a ese volumen). - Volumen del Mic en aumix a 89: la grabacion esta a un volumen un poco mas alto que el sonido emitido, pero todavia no se nota que este mal grabado. Puede dar problemas si se graba a un volumen algo saturado al rojo. - Volumen del Mic en aumix a 91: la grabacion esta a un volumen bastante mas alto que el sonido emitido, por lo que es facil que se sature al rojo. Por lo tanto, pongo la ayuda de garraxi, seccion admin, que el volumen bueno es el 86 (con screenshot y todo :-)). Pero me doy cuenta que en ocasiones el volumen al que grabamos baja sin que haya explicacion alguna. Luego me doy cuenta que el problema coincide con reinicios salvajes del servidor, sin que se apague adecuadamente (donde hay un comando que guarda la configuracion del sonido para restaurarla tras el arranque). Asi que el problema es que despues de modificar el volumen de las tarjetas de sonido, no guardamos sus configuraciones, con lo que si no se apaga adecuadamente el server, no esta guardado el cambio realizado y se vuelve al estado anterior. La solucion es correr el comando 'alsactl store' como root, con lo que guarda todas las configuarciones de los mixers de todas las tarjetas de sonido actuales. El estado de las tarjetas se guarda en /var/lib/alsa/asound.state. Pongo en el script de los mixers que al final, antes de salir se haga un 'sudo alsactl store'. Para ello tengo que dar permisos a garraxi2 para que pueda hacer 'sudo alsactl'. Mas tarde comprobamos (en el cursillo de radio que hacemos) que todas las grabaciones salen con la voz un tanto metalica (sobre todo cuando metemos voz desde el telefono, pero tambien con la voz desde los micros). Parece ser que el problema viene de la tarjeta de sonido que graba (la SB16). Pruebo a grabar con ella con diferentes configuraciones, pero siempre se nota el mismo tipo de sonido metalico. Las pruebas hechas han sido: - Variar el bass y treble de la tarjeta, pero eso no parece modificar nada la grabacion, posiblemente solo le afecte a la emision de sonido por esa tarjeta. - Mirar a grabar desde la linea en vez del micro, cambiando la clavija de conector y tambien en aumix desde donde grabamos. El resultado es similar. - Ver la diferencia entre grabar en ogg o en wav con la misma configuracion (grabando desde el micro de la tarjeta, y con el mismo volumen de este, 86), pero el resultado es similar en ambos formatos. Probablemente el problema es que la grabacion desde esa tarjeta no es del todo buena por el hardware de la tarjeta. Pruebo tambien a grabar en el ordenata auxiliar, con la mierda de tarjeta integrada que tiene y aqui se nota algo menos la voz metalica, aunque graba con un sonido bajo repetitivo (una especie de chasquido bajo repetitivo). Grabando tambien con la tarjeta del servidor que utilizamos para emitir tambien se nota cierta mejoria, no demasiado. Comparando muestras grabadas con sox, en formato wav, con el resto de setings de sox iguales, con los volumenes de ambas tarjetas puestos parecidos y tratando de hablar similar, la tarjeta que utilizamos para emitir (PCI ES1371) graba con menos sonido metalico (aunque todavia se puede apreciar algo), que la que utilizamos para grabar (ISA SB16). VER DE MEJORAR EL HARDWARE Y PILLAR UNA TARJETA DE SONIDO MEJOR?? COPIA DE SEGURIDAD CRUZADAS DEL SERVER EN EL AUX Y ALREVES: El objetivo es hacer copias de seguridad semanales en el server y en el aux de /etc, archivos ocultos de la home de garraxi, listado de paquetes instalados y otros archivos importantes como logs de soma y scripts en /usr/local/bin. Guardar varias copias de esos backups, con savelog, que rota las copias, en el propio ordenador donde se hacen. Despues en el aux, cada vez que arranque, que compruebe si esos backups del server y del aux son diferentes que los que hay en un ordenata y en el otro y si es asi, que los copie de uno al otro, para tener siempre una copia identica en otro ordenata diferente. 1. Backup de los archivos importantes en el propio ordenata con ibackup: * Poner en /etc/ibackup.conf que los datos se guardan en /home/garraxi2/backups/[aux|server]. y que se comprimen. * Para poder rotar los archivos con savelog el nombre del backup no debe tener fechas. Para conseguirlo modificar el script /usr/bin/ibackup. Esto se hace en la linea 332 del script, quitandole lo de `date +%d%m%Y_%H%M%S`. * Creo una config propia ('garraxi') sobre lo que backupear, que es un mix de la config 'linux' y 'userconf' (guardando las homes de garraxi, garraxi2 y root) mas los añadidos de: backupear todo el contenido de /var/log/soma y tambien /usr/local/bin/*.sh (scripts mios). Esta conf se añade a las que ya hay en el script /usr/bin/ibackup. case $@ in *garraxi*) rm -rf /tmp/sysinfo mkdir -p /tmp/sysinfo which dpkg >/dev/null && dpkg -l >/tmp/sysinfo/deb_installed which dpkg >/dev/null && dpkg --get-selections >/tmp/sysinfo/deb_installed_gs dmesg >/tmp/sysinfo/dmesg fdisk -l >/tmp/sysinfo/fdisk-l ifconfig >/tmp/sysinfo/ifconfig netstat -nr >/tmp/sysinfo/netstat-nr netstat -plunt >/tmp/sysinfo/netstat-plunt netstat -s >/tmp/sysinfo/netstat-s dir="$dir var/spool/cron etc tmp/sysinfo/* boot/grub/menu.lst boot/config* var/log/soma usr/local/bin/*.sh var/lib/alsa/* `find /home/garraxi -maxdepth 1 -name .\*` `find /home/garraxi2 -maxdepth 1 -name .\*` `find /root -maxdepth 1 -name .\*`" ;; esac * Creo los scripts 'copiaseg-server' y 'copiaseg-aux' para cron.weekly para backupear lo anterior y rotarlo con savelog, guardandolo en el propio ordenata: ibackup garraxi; savelog -c 7 -l /home/garraxi2/backups/[aux|server]/garraxi.tar.gz >/dev/null exit 0 En el server, el script lo ejecuta semanalmente cron. En el aux lo ejecuta anacron, dado que al no estar en marcha continuamente necesita un cron anacronico :-D. El uso de anacron es similar al de cron, tan solo hay que poner los scripts que se ejecutaran en el dir /etc/cron.[daily|weekly|monthly]. 2. Backup de esto en el otro ordenata con cpbk en el arranque del aux: * Creo el script 'copiaseg-aux.init.d' que: 1. Monta el dir de backup del server en un dir tmp del auxiliar a traves de nfs. Para ello, primero en el server añadir garraxi2/backups a /etc/exports. En el auxiliar crear los dir garraxi2/backups/aux y server (donde se crean los backups del aux, y donde copiaremos los archivos de backup del server respectivamente). En el server tambien se crean los mismos directorios (garraxi2/backups/aux y server), donde copiaremos los archivos de backup del aux y donde se crean los backups del server respectivamente. En el script copiaseg-aux.init.d poner que se crea un dir temporal y se monta en él el garraxi2/backups/ del server: mkidr /tmp/backups-server; mount -t nfs -o user,auto,rsize=8192,wsize=8192,timeo=14,intr 192.168.0.1:/home/garraxi2/backups /tmp/backups-server 2. Copiar los backups del server en el auxiliar, y los backups del aux en el server, solo si hay cambios, usando 'cpbk dirdeorigen dirdedestino': cpbk -q /tmp/backups-server/server /home/garraxi2/backups/server; cpbk -q /home/garraxi2/backups/aux /tmp/backups-server/aux; 3. Desmontar el dir de backup del server en el aux. y borrar el dir temporal: umount /tmp/backups-server; rmdir /tmp/backups-server; * De este modo pongo dicho script en aux:/etc/init.d. Lo llamo para que se ejecute en el arranque del ordenata auxiliar, creando el enlace simbolico hacia él desde aux:/etc/rc2.d/S99copiaseg-aux.init.d. Compruebo que esta parte funciona perfectamente: cada vez que hay nuevos archivos en los dirdeorigen, se copian al dirdedestino :-D. Despues de instalar anacron en el aux, compruebo que en un ordenata de sobremesa (que no es un servidor) los demonios cron y atd no tienen sentido dado que ese trabajo lo hace perfectamente anacron (se activa al poco de arrancar el ordenata y realiza los trabajos de cron diarios, semanales o mensuales). Ademas, en este tipo de ordenatas: - cron solo es necesario para arrancar de nuevo anacron despues de haber estado todo un dia encendido (no suele ser nuestro caso, y cuando ocurra tampoco pasa nada si no se arranca). - atd solo es necesario si queremos poner tareas que se ejecuten a determinadas horas, y con determinadas condiciones de carga del procesador, pero no hay ninguna tarea del sistema (de Debian) que controle atd. Asi que finalmente quito del arranque del ordenata auxiliar (update-rc.d -f demonio remove) los demonios cron y atd. ========================================== TEMAS PENDIENTES (ver por arriba mas info): - PROBAR A GRABAR Y EMITIR A LA VEZ POR LA MISMA TARJETA (para comprobar el fullduplex de ALSA). No importante, porque tenemos dos tarjetas, pero puede ser importante en caso de necesidad. - HACER PRUEBAS DE AUDICION BUENAS CON UNA CANCION RIPPEADA A DIVERSAS CALIDADES Y ESTABLECER CUAL ES LA CALIDAD ADECUADA A NUESTRAS NECESIDADES. Ahora tenemos 112 Kb/s = q3 en ripperX y q2 = 90 kb/s en sox/flrec. - VER COMO TAGGEAR/RENOMBRAR/PONER EN DIRECTORIOS ADECUADAMENTE LOS ARCHIVOS QUE NOS PASE LA PEÑA TODOS DESORGANIZADOS. PONERLO COMO TAREA DEL ADMIN DE LA EMISION ? (Solo si es frecuente). - Posible scrip para cron (hourly?) para que compruebe si somad esta levantado y si no lo levante. Util si somad se callera habitualmente. El problema esta en ¿que pasa si el user esta haciendo un programa y ha quitado somad para usar otro programa?: - comprobar si somad esta arrancado (somaclient -ssl -p --running). - si NO -> comprobar si otro programa ocupa la targeta de sonido (¿como?). - si NO -> comprobar si un user esta usando los cd's o algo para emitir: - Pregunta con Xdialog "¿hay alguien ahi?, con timeout de 5 minutos... - si en esos 5 min. el user no le da al OK, cron intentaria arrancar somad. - si no lo consigue, sacar el output de somad en una ventana de xdialog. Pero el problema es que muchas veces somad ha dejado de sacar sonido pero sin dejar de estar "vivo", como cuando el archivo de sonido que esta tocando esta chungo... - Pensar para el futuro si poner UN ESCRITORIO COMPLETO, LIGERO Y COSTUMIZABLE COMO EL DE XFCE. Por ejemplo para que la gestion de archivos sea mas facil (rox es un poco lio), que los iconos del escritorio sean mas bonitos, y que haya un poco mas de integracion entre aplicaciones. Darle una pinta mas a la windoze, no tanto como Gnome que traia la Xevian.