Molesta pausa al reproducir archivos de audio

Adjunto que use el comando sudo renice -20, con Vlc no note mejorías, con aqualung seguía escuchando el salto de audio, y con el totem igual la pausa mmm...

Saludos

Con nice (corresponde a la columna NI de ps) cero significa prioridad normal, un número positivo indica menos prioridad de la normal (más "nice" con los demás procesos), un numero negativo indica más prioridad (menos "nice" con los demás procesos).

nice --10 : más prioridad de lo normal (-10)
nice -10 : menos prioridad de lo normal (10)

La columna PRI sólo tiene uso para procesos que usan scheduling de tiempo real, como SCHED_FIFO o SCHED_RR. Los procesos normales usan SCHED_OTHER y siempre tendrán menos prioridad, nice se usa para priorizar estos procesos.

http://ccrma.stanford.edu/planetccrma/man/man2/sched_setscheduler.2.html

Alguien escribió:

SCHED_OTHER is the default universal time-sharing scheduler policy used
by most processes, SCHED_FIFO and SCHED_RR are intended for special
time-critical applications that need precise control over the way in
which runnable processes are selected for execution. Processes sched-
uled with SCHED_OTHER must be assigned the static priority 0, processes
scheduled under SCHED_FIFO or SCHED_RR can have a static priority in
the range 1 to 99. Only processes with superuser privileges can get a
ordering within the list of runnable processes with equal static prior-
ity.

Ok, Leeré más sobre prioridades de procesos, la otra pregunta que tengo es que los mensajes de jack dice que se inicia con prioridad 89, pero en la salida de ps sigue teniendo de PRI=80 y NI=0, como la mayoría de procesos, segun creo dice que corre con prioridad mormal, entonces, donde esta el 89, será que si doy esa prioridad a los programas de audio funcionarán estos mejor?. Voy a buscar información de como trabaja jackd, también voy a probar con algunos livecd a ver cual funciona normal y tratar de ver que diferencias hay en los programas o versión de alsa que estos usen, seguire probando y buscando, aprendiendo...

Saludos.

En realidad la prioridad no es de los procesos, sino de los threads (hilos), un proceso puede tener varios threads.

Generalmente una aplicación de audio que no use jackd tendrá al menos dos threads, uno de interfaz de usuario que debería ejecutarse a baja prioridad (controla la respuesta del programa a eventos provenientes del ratón o el teclado) y otro de procesamiento de audio, que responde a eventos provenientes de la tarjeta de audio a través del backend que se esté utilizando (normalmente ALSA o PulseAudio, más raramente OSS).

Lanzar una aplicación con nice o chrt no es la mejor solución porque también se sube la prioridad de sus threads que no son de audio, simplemente te hice la sugerencia por ver si de alguna manera un poco chapucera subir la prioridad del reproductor respecto al resto de aplicaciones ayudaba a reducir los problemas de buffer de audio que estás teniendo.

En el caso de una aplicación jack, ésta no tiene un thread propio de audio. Lo que sucede es que la aplicación registra sus funciones de procesamiento de audio (callbacks) con el servidor jackd y éste las procesa en su(s) thread(s) de audio de alta prioridad.

Otra pregunta. Si coges un MP3 y lo recodificas a WAV, ¿al reproducir el WAV tienes menos cortes que al reproducir el MP3? En caso de que sí, dejaría muy claro que el problema es de CPU y no de disco.

Hola, ya lo había hecho, pero lo he vuelto a hacer para tratar de contar las veces que ocurre el error

La verdad es que es aleatorio, a veces el wav produce menos errores que el que el mp3 y a veces más (parecería que ni wav puedo reproducir )

Saludos.

Pues entonces no sería un problema de falta CPU, porque la mayor parte de procesamiento se dedica a descomprimir el MP3 en tiempo real, mientras que reproducir un WAV es simplemente mandar las muestras del disco al dispositivo de audio (a no ser que el WAV y la tarjeta estén en frecuencias de muestreo distintas, en cuyo caso hay que hacer resampling que sí consume bastante CPU).

En fin, si ves que con jack te va bien, puedes jackificarlo prácticamente todo.

Parece que con esta versión de debián esa es la manera en que funciona con este chip de sonido, he visto en otros lados que así lo solucionan, pero antes de tirar la toalla voy a investigar más, en cuanto consiga cds virgenes quemare algunas distrosen livecds para ver como se comporta el sonido, tal vez comparando logre encontrar algo,también voy a ver si compilo el kernell, no creo que ayude mucho pero quien sabe, lo que sí se es que una vez compile el kernell en otra máquina también un poco antigua y el rendimiento de todo mejoró bastante, intentaré probar esto este fin de semana, pero antes voy a conseguir las distros.

Saludos

Hola, de nuevo.

Bien, les cuento las pruebas que he hecho hasta ahora:

-Primero desinstale totalmente gnome y cualquier otro escritorio que no sea blackbox
-desinstale el gdm, asi como el xdm

Luego corrí el mplayer para reproducir los archivos con los que siempre hago pruebas, el resultado fue lo mismo, pausa escuchada

-Probe con otra distro, Xubuntu 8.04, bueno, despues de cruzar los dedos, con esta no escuche ninguna pausa, bueno, por lo menos otra froma de reproducir audio encontrada, no probe ninguna otra aplicación de edición de audio debido a que era un livecd y mi poca ram.

-Me pase el fin de semana compilando el kernel,antes leyendo y buscando google todo lo posible sobre las opciones del menu, encontre información sobre algunas que me llamaron la atención, mas sobre estas:

Preemtion Model. esta tenia tres opciones: No forced preention(server), Voluntary kernel(desktop), Preentible kernel(realtime). Lehí que para escritorio y multimedia recomendaban "Preentible kernel", aunque me imagino que eso era para pcs mas potentes, solo por experimentación puse esa opción


La otra opción es del timer frecuency, la mayoría recomiendo poner un valor de 1000, aunque esta si me dió miedo cambiarla a ese valor, puse un valor intermedio, 250

Despues de compilar e instalar el kernel, inicié con el kernel nuevo, luego lanze mplayer sin lanzar las x, probe con un archivo corto (uno con el que siempre empiezo las pruebas, a 22khz y de 3 minutos) y lo escuché sin pausas, luego lanze un archivo un poquito más pesado (40Khz) y lo note un poco sucio,(o sea ciertos ruiditos como pequeños cortes, a parte de eso era como si se ralentizaba un poquitin)bueno, esperé un poco y volví a probar con el archivo anterior a 20khz y ,para mi mala suerte, volví a escuchar las pausas, recordé que el orden en que aparecen las pausas es aleatorio y que rara vez no aparecían siel archivo era corto, seguí probando con vlc y jack, no hubieron problemas como siempre aunque si le costó ahora reproducir ese archivo a 40khz, un poco menos que el mplayer pro le costó, antes no me pasaba eso.
Creo que eso pasa por las opciones que mencione antes, la del "Preemtion Model" y la del "Timer Frecuency", creo que hace que mi procesador trabaje más, en fín, resultados:el audio se me empeoro un poco, pero a cambio el sistema me va un poquito más rapido y el video también mejoró (hubiera preferido que sea al revez).Con todo volví al kernel anterior, ya encontraré tiempo para volver a compilar el kernel.

Tratando de buscar otra solución quisiera comparar la versión de xubunto que me funcionó (8.04) con mi squeeze para ver que versión de archivos hay de diferencia, así como procesos ejecutandose, opciones del kernel, en fin, tal vez cambiando algo se solucione esto de forma más sencilla. quisiera que me sugirieran que más podría observar en la comparación de estas distros.

Geracias de antemano y saludos!!

Bueno, Holas de nuevo!!

Bien, depues de haber estado ocupadisimo arreglando el cuarto de mi hijo, he estado probando compilando el kernel con diferentes configuraciones para ver si se solucionaba mi problemilla pero para lo unico que ha servido todo esto es para darme cuenta de mi bajisimo nivel de conocimiento de Linux

Bueno, entonces me quede con dos opciones: la de jacktificar la saida de mis programas reproductores de audio y/o video funcionaba, pero a costa de consumir mas recursos (un poquito mas de recursos en un pc como el mio se nota) asi que me tuve que ir por la segunda que fue incluso la primera sugerencia que recibi: Sabia que con equipos muy parecidos al mio ese probema aparecia a raiz de haber actualizado de ubuntu 9.04 a 9.10 (por tomar un caso) como habia probado con xubuntu 8.04 decidi borrar Debian Squeeze y poner Xubuntu Hardy (felizmente habia particionado el /home aparte asi que no perdi datos). El resultado fue un sistema mas agil, y aunque ciertas versiones de librerias graficas eran antiguas el audio iba normal, aunque el video no tanto, tenia agunos videotutoriales en flv que ni el totem, ni vlc y ni mplayer o xine pudieron reproducirlos.probe instalando montones de codecs pero nada, en otros lados me decian que la solucion era actualizar el sistema a una version mas nueva pero eso si no lo hago, ya que entre audio y video prefiero el audio. Investigando por google lehi que el vlc a partir de versiones superiores a la 0.94 empezaba a leer flv sin problemas, decidi entonces instalar el vlc 1.01 que lo encontre en deb, pero al hacerlo manualmente me pedia instalar dependencias que a la vez me pedian otras,asi que decidi dejarlo.

Asi que lo que hice fue hacer un backup de mi sourcelist, luego cree uno nuevo con los repositorios de ubuntu 10
y lanze un apt-get update (eso es algo que todo el mundo recomienda o advierte no hacer para evitar conflictos o volver inestable el sistema pero como solo me fataba el asunto de los flv y el sistema estaba recien instalado decidi arriesgarme) Luego mande a instalar el vlc, version mas actualizada que la de xubuntu 8.04, y se me actualizaron un pocoton de cosas, entre ellas las gtk y otras librerias que manejaban fuentes. Reinicie el sistema y a probar. Al haber hecho esto se desconfiguraron los paneles de xfce, pero el vlc funcionaba normal.Probe aplicaciones de audio y tampoco dieron problemas a exepcion de Jamin que cargaba al procesador mas del 100% y quedo inutilizable, con el 8.04 recien instalado tambien cargaba el procesador cerca del 75%, no podia usar demasiados efectos pero por lo menos sonaba (cabe destacar que con el squeeze se colgaba a penas abrirlo). Bueno, despues de todo con las herramientas que tengo disponibles al momento es factible hacer musica asi que voy a tratar de dejarlo ahi, mi conclusion es que son las librerias que se actualizaron las que cargan el sistema, pero bueno, tratare de convertir todos los flvs que tengo a mp4 u otro formato que lea el xubuntu 8.04 (los reproductores incluidos)para despues en una futura reinstalacion no tener que actualizar el sistema y quedarme con lo que mas funciona (aunque debo admitir que el vlc actualizado reproduce los videos mejor pero bueno..eso es tema de otro foro). DOY MUUUUCHAS GRACIAS a todos los que me habeis respondido ya que gracias a ustedes he aprendido un poco mas sobre Linux, la verdad que buscar soluciones a problemas en Linux se vuelve altamente aditivo!!, ojala ue deje de resolver problemas y dedique mas tiempo a hacer musica con el ordenador.


Saludos a todos... la proxima semana declaro este tema como solucionado y perdon por la ortografia, esque escribo desde un teclado en ruso