Wilma FAQ 2
by SawTooth
http://members.nbci.com/toothsaw
1) El sonido decodificado no es fluido. Se oye entrecortado.
2) El sonido decodificado se oye distorsionado, con ruidos.
3) ¿Cómo cambio la sensibilidad de Autodetectar de Wilma?
4) AutoDetección a veces se activa o apaga cuando no debería
5) El regulador del volumen de entrada (al lado del medidor) no afecta al volumen (ni al medidor) El botón Silenciar no silencia el sonido.
6) La voz no está sincronizada con las imágenes, se oye después de que los actores hayan hablado.
7) ¿Puede medirse la desincronización imagen – sonido?
8) ¿Cómo funciona la ventana de medida de temporización del Buffer?
9) ¿Puedo reducir el uso de CPU de Wilma?
10) ¿Para qué sirve la opción Prioridad? No noto diferencia al cambiarla.
11) ¿Cómo maneja Wilma el Mezclador?
12) He editado manualmente el archivo Wilma.ini, y ahora tengo problemas.
13) Tengo una tarjeta WinTV NICAM y no escucho sonido con algunos visores de TV
14) El volumen del sonido decodificado es muy alto, ¿Qué puedo hacer?
15) Uso Win95 y no veo las imágenes de la Barra de Herramientas de Wilma.
16) En Modo Wide, obtengo el sonido muy bajo. Tengo la tarjeta de sonido conectada a un dispositivo externo mono mediante un convertidor o adaptador estéreo-mono.
17) ¿Cómo funciona la característica ‘Transmitir Autodetección’?
R) Necesitas aumentar el número de buffers de grabación. Este número depende del tamaño de buffer, de la tarjeta de sonido (ISA o PCI), velocidad de CPU, y también si hay aplicaciones de 16 bits ejecutándose. Simplemente ve aumentando el número de buffers hasta que el sonido sea fluido, y añade un buffer más por seguridad. No añadas más de los necesarios. Mira el número de Buffers Perdidos, y asegúrate de que no aumentan en un minuto, si no es asó, añade otro buffer más, etc...
R) El volumen está demasiado alto, en algún punto de la línea. Puedes probar a:
Sin embargo, si el voltaje o impedancia de la salida de sonido de tu TV no es adecuado a entrada de sonido que has elegido, obtendrás distorsiones. Evita usar la entrada del Micrófono si es posible. Si la usas, desactiva ‘Mejorar’ del micrófono en tu Mezclador.
R) Hay dos factores que afectan la sensibilidad de Autodetectar de Wilma, o lo rápido que Wilma detectará un cambio en la codificación de la señal: el volumen del sonido de Entrada, y la cantidad de ruido de baja frecuencia en la señal. La Autodetección requiere un nivel mínimo de volumen de Entrada. Si el cambio de la codificación no se detecta rápidamente, asegúrate de que el medidor VU llega al menos al 20 o 25%, y preferiblemente a mucho más. Sin embargo, si el volumen está demasiado alto, y el medidor VU está siempre rojo, pueden producirse detecciones incorrectas. Así, para conseguir una detección fiable, haz que el nivel de volumen esté por encima del 20% pero por debajo del 80%.
Para el ruido en la señal, la configuración predeterminada es ‘Fiable’ para tolerar gran cantidad de ruido de baja frecuencia en sonidos codificados. Si quieres probar a aumentar la sensibilidad, debes fijarte en el Analizador de espectro de la señal de Entrada mientras escuchas sonido codificado. Si el pico de bajas frecuencias (a la izquierda de la gráfica) llega a -40dB, no esperes aumentar la sensibilidad sin causar fallos en la detección. Si no llega a -60dB puedes intentar aumentar la sensibilidad.
El otro factor que afecta a la velocidad de la autodetección es el número de confirmaciones extra. Cada vez que se detecta un cambio en la codificación, se requiere una detección FFT que confirme el cambio. Esto sucede tanto si usas el método normal o el FFT. Por defecto, las Confirmaciones Extra son cero, lo cual significa que lega con una confirmación. Si quieres experimentar, puedes aumentar la sensibilidad, y si aparecen detecciones falsas, aumentar el número de confirmaciones. Esto nos daría una detección igual de fiable, pero algo más rápida. Sin embargo, sigue dependiendo de la calidad y el volumen del sonido de Entrada.
R) Si sucede cuando el sonido no está codificado, aumento el volumen de Entrada. Si sucede cuando el sonido está codificado, disminúyelo.
R) Asegúrate de que la tarjeta de sonido y la entrada que has seleccionado corresponden a la que el sonido de la TV está conectado. El botón Silenciar debería silenciar el sonido original codificado, no el decodificado. Para parar el sonido decodificado, pulsa los botones Decodificar o Activar.
Si tienes dos o más tarjetas de sonido conectadas en cascada (la salida de una conectada a la tarjeta de la siguiente, etc ...) asegúrate de que seleccionas la entrada de la última (a la que tienes conectados los altavoces).
R) La mala sincronización puede deberse al programa o película que estés viendo, especialmente si está doblada.
Sin embargo, siempre hay cierto retardo debido al proceso multitarea grabación – decodificación – reproducción. El uso de buffers excesivamente grandes puede producir grandes retardos, pro Wilma no permite seleccionar tales tamaños. Sin embargo, escoger un número de buffers mucho mayor al necesario para tener sonido continuo, también acrecentará el retardo.
En general, intenta usar tamaños de buffer entre 500 y 2000 bytes. Los tamaños pequeños resultarán en retardos menores, y menores interrupciones cuando se pierde un buffer de vez en cuando, pero consumirá algo más de CPU. Si seleccionas muchos más buffers de los necesarios, el retardo irá creciendo. Si notas este efecto, reduce el número de buffers al mínimo número necesario para tener sonido entrecortado.
Si estás interesado en los detalles técnicos, aquí tienes un ejemplo usando buffers de 882 bytes (la configuración Pequeños) con una tarjeta de sonido SBLive:
El decodificador recibe los buffers de sonido obviamente después de que hayan sido grabados (se tarda exactamente 10 ms en grabar un buffer de 882 bytes mono con muestreo 16-bit a 44100Hz). Estos buffers se procesan muy deprisa (sobre 0.2ms por buffer), e inmediatamente los envía para ser reproducidos. Asumiendo que el buffer enviado se reproduce inmediatamente, esto nos da un retardo total de alrededor de 10.2 ms, que es caso imperceptible.
El razonamiento anterior asume varias cosas:
1) Que cada 10ms de grabación nos legará inmediatamente el buffer que ha sido grabado.
2) Que cada 10ms será reproducido un buffer inmediatamente.
Como podrás imaginar, las aseveraciones de arriba no son del todo ciertas. Los drivers de sonido de Windows usan buffers DMA de grabación y reproducción de tamaño fijo. Al grabar, esperan a que el buffer DMA se llene, entonces usan los datos para rellenar pequeños buffers de 10ms y nos los devuelven. Así, sólo recibimos buffers de grabación cuando el buffer DMA correspondiente está lleno, a intervalos correspondientes a la capacidad del mismo. Por ejemplo, en la SBLive, el buffer DMA de grabación es de 5120 bytes (58 ms), por lo que recibimos 5 o 6 buffers de 10ms cada 58ms.
De forma similar, en la reproducción, el driver de sonido usa un buffer DMA de reproducción de tamaño fijo. En la SBLive, su tamaño era de 11024 bytes (62.5 ms estéreo). Por esto el driver reproduce los buffers de 10 ms cuando ha recibido 7 de ellos.
Cuando empezamos a grabar, sólo recibimos 5 buffers, pues el driver sólo tiene 58ms de sonido, y sólo puede completar y devolver 5 buffers. Cuando procesamos y enviamos 5 buffers para su reproducción, estos no son reproducidos, pues se necesitan 7 buffers para ello. Esto significa que la salida de sonido comenzará cuando se reciban los siguientes buffers de grabación, 58 ms después.
Esto nos da un retardo inicial total de 2*58 = 116ms. Si esta situación se mantiene, el retado sería constante e igual a 2 veces el tamaño del buffer de grabación DMA (en el caso de la SBLive, cuyo buffer de reproducción es más grande que el de grabación).
Pero esta situación no se mantiene mucho tiempo, por la simple razón de que los buffers de entrada y salida DMA tienen tamaños diferentes. Es bastante complicado de explicar, pero intuitivamente, puedes imaginarte que el retardo cambiará en el tiempo. Cuanta más diferencia hay, más grande el retardo. Por ello, para mantener el retardo en límites razonables, debes mantenerlos bastante cercanos.
Esto significa:
1) Evitar usar grandes tamaños de buffer
2) Evitar usar gran número de buffers
Para que puedas compara, la SB16 PnP ISA usa un buffer de grabación DMA de 125ms (16-bit mono), y de reproducción de 62.5ms (16-bit estéreo).
Si quieres descubrir la capacidad de los buffers DMA de grabación y reproducción de tu tarjeta de sonido, usa la pantalla de medición de Buffer (pulsando Ctrl-W). La capacidad del buffer DMA de grabación es indicada en "Avg. Out Buffer Receive Period". La capacidad de los buffers de Wilma es indicada en “Acquisition" en esta pantalla.
Para ver la medición desde el principio, asegúrate de que el botón delgado a la izquierda del botón “Start” está pulsado antes de comenzar.
Es interesante mirar el "Avg. Out Buffer Round Trip". Muestra cómo el retardo tiende a aumentar en el tiempo. Aunque este retardo NO es la latencia (es decir, la diferencia entre el movimiento de los labios y el sonido), suelen asemejarse mucho. Observa cómo el retardo va aumentado gradualmente, y después disminuye bruscamente cada vez que se pierde un buffer de salida. De nuevo, repito que este retardo no es la latencia, pero esta, como he podido comprobar, se comporta del mismo modo. Escoge un tamaño de buffer pequeño y compara el retardo con el que obtienes cuando coges tamaños grandes (en ambos casos, ajusta el número de buffers al mínimo necesario).
Resumiendo, parece que no hay forma de cambiar el tamaño de los buffer DMA sin escribir un nuevo driver.
Si tienes experiencia u observaciones sobre este tema, déjame oírlas.
R) Para medir e retardo del procesamiento de sonido, necesita una fuente externa de sonido en forma de pulsos (por ejemplo una grabación de palmadas cada 2 segundos). Introduce este sonido en tu tarjeta de sonido por la Entrada de Línea, y haz que Wilma decodifique este sonido, pero no silencies el original (debes oír ambos sonidos).
Ahora debes fijarte en la salida de tu tarjeta de sondo. Puedes usar un osciloscopio, o bien grabar la salida en una cinta, aunque si lo haces, luego deberás volver a grabarlo en el PC como archivo WAV. Después abre el archivo usando un buen editor de onda, y observa el retardo entre el sonido original y el decodificado. Si grabas el tiempo suficiente, verás que el retardo va aumentando poco a poco, y luego decrece de golpe (cuando se pierde un buffer).
R) En primer lugar, para acceder a la ventana de temporización del Buffer, presiona Ctrl-W, o abre las opciones de Wilma y haz doble-clic en la etiqueta ‘Wilma!’. Puedes presionar el botón Start en una nueva ventana en cualquier momento, incluso aunque Wilma no se esté ejecutando.
Si Wilma no se está ejecutando, al pulsar Start se ejecutará, y así podrás ver el tráfico del buffer desde el principio. Si Wilma ya se está ejecutando, verás el tráfico a partir de ese momento. Si quieres que siempre se monitorice el buffer desde el inicio de Wilma, pulsa el botón delgado a la izquierda del botón Start antes de pulsar este último.
La lista se llena con la información de 300 buffers de entrada y 300 de salida. Deberías esperar a que esta información sea recogida, lo cual tarda más cuanto más grandes sean los buffers. También puedes interrumpir el proceso pulsando de nuevo el botón Start. Si el proceso tarda más de 15 sg. Será automáticamente detenido.
Si quieres ver cuando se ejecutan las tareas principales en comparación con las de decodificación, mueve el ratón sobre la ventana principal de Wilma mientras se ejecuta el test. Las entradas con el nombre 'MainThread' indican el momento en el que las tareas principales se ejecutan dentro de su espacio de tiempo. Notarás que sólo se ejecutan una vez que el “paquete” de buffers ha llegado.
Puedes guardar los resultados en un archivo llamado 'Timing.txt' presionando el botón 'Save'. Te agradecería mucho si me pudieses enviar este archivo, pues podría ayudarme a aprender mucho sobre diferentes tarjetas de sonido. Gracias.
Wilma maneja los buffers de la siguiente forma:
Llega un buffer de entrada, lleno. Es inmediatamente decodificado al buffer correspondiente de salida. El buffer de salida es inmediatamente enviado para su reproducción, y el buffer de entrada se reenvía para la grabación. Después e cierto tiempo, el buffer de salida debería volver tras haber sido reproducido, seguido del buffer de entrada lleno de nuevo. Se pierde un buffer de salida cuando llega uno de entrada antes que él. En este caso Wilma simplemente reenvía el buffer de entrada (ni lo decodifica ni lo reproduce).
Cuando la lista esté llena, aparecerán algunas estadísticas sobre la temporización del buffer.
'Receive Period' es el tiempo entre la llegada de un paquete de buffers y la llegada del siguiente del mismo tipo (entrada o salida). ‘Average’ hace una aproximación del buffers que los buffers DMA de tamaño fijo de tu tarjeta de sonido está usando para grabar (Buffer de Entrada) y reproducir (Buffer de Salida).
'Round Trip' es el tiempo que un buffer tarda en ser reenviado, desde que es enviado. Las cifras en colores iguales están relacionadas entre sí. Tiempos excesivamente cortos, son imposibles o ilógicos, y aparecen en rojo. Generalmente significa que no hay buffers suficientes. Sin embargo, si haces un test desde el principio, es normal que los primeros buffers de salida sean inmediatamente devueltos, por lo que en este caso es normal tener cifras pequeñas en ‘Minimum Output buffer Round Trip’.
El hecho de que un buffer de salida se pierda cada poco tiempo, aun usando un número suficiente de buffers indica que el retardo está aumentando. Una de las causas de este aumento puede ser que los buffers de grabación y reproducción DMA no sean del mismo tamaño (Avg. In Buffer Receive Period distinto de Avg. Out Buffer Receive Period). Otra causa podría ser una interrupción debida a los cambios de tarea.
Wilma v1.1, buscaba el primar buffer de salida disponible para reproducir el buffer entrante (los buffers de entrada y salida no estaban correlacionados). Mientras haya buffers suficientes, no se pierde ninguno. Si tienes esta versión (que todavía está disponible) notarás que se necesitaban aproximadamente 3 veces más buffers de salida. Además, si repites el test de temporización después de algún tiempo, observarás que el número de buffers de salida necesarios han. Esto explica la necesidad de resetear el sonido cada poco en la 1.1 para reducir el retardo. Wilma v1.2 y superior usan una técnica diferente para minimizar el retardo: cada buffer de entrada tiene uno de salida asociado. Si el buffer de salida no está listo cuando llega el de entrada, ese buffer se ignora (como un frame en un vídeo), y así el retardo no sigue aumentando. Pero cuantos más buffers pongas por encima del mínimo necesario, más permitirás que aumente el retardo en el tiempo.
R) El uso de CPU por Wilma se ha reducido mucho desde la versión 1.5. Si aún así necesitas reducir el uso de CPU, puedes hacer lo siguiente:
Nota: Puedes usar WinTop, una utilidad de Microsoft, para medir el uso de CPU. No muevas el ratón sobre una aplicación mientras mides el uso de CPU. WinTop era parte de los ‘Toys’ del Kernel de Win95 y puede descargarse aquí : http://www.microsoft.com/windows/downloads/bin/W95KRNLTOYS.EXE
Otra aplicación muy útil es ATM (Another Task Manager = Otro gestor de tareas), Pues también calcula el uso medio de la CPU de cada tarea. Para resetear la medición debes reiniciar ATM. http://atm.idic.caos.it
sumsara