Hola,
Alguien escribió:
Qué juego más divertido. Mi récord es 0,308 s pero cuesta un poco bajar de 0,4. No he practicado mucho rato de todas maneras. Con los cronómetros de los relojes digitales mi récord era 0,07 s, aunque bajar de 10 centésimas era todo un triunfo.
Estoy probando jack_delay. Tengo gnome con los efectos de escritorio activados, las dos CPU's en modo perfomance, un kernel 2.6.31-rt, una m-audio 2496, ahora mismo compartiendo número de IRQ con la HDA-Intel integrada (estoy haciendo pruebas)... Con qjackctl, patchage y jack_delay, con 48000 Hz, 32 caudros por periodo y dos periodos por buffer. Sin apenas xruns (2 ó 3 en 5 minutos). Si bajo de ahí, jack arranca (que ya es bastante) pero vienen muchos xruns ahora mismo aunque creo que lo puedo evitar si inhabilito la integrada y hago otros ajustes (demasiado trabajo para algo inútil).
Latencia calculada de bucle completo (y mostrada en qjackctl):
(32 x 2) [frames] x 48000 [frames / s] = 0,00133 s = 1,33 ms
Latencia real mostrada por jack_delay:
pablo@desktop:~$ jack_delay
capture latency = 32
playback_latency = 32
(signal below threshold hasta que hago las conexiones virtuales entre jack_delay y system)
122.611 frames 2.554 ms
122.610 frames 2.554 ms
122.608 frames 2.554 ms
122.607 frames 2.554 ms
122.609 frames 2.554 ms
122.608 frames 2.554 ms
122.608 frames 2.554 ms
...
Desde 64 hasta 123 frames, o lo que es lo mismo, desde 1,33 hasta 2,55 ms son 59 frames o 1,22 ms.
Esta diferencia entre latencia calculada y latencia real de bucle completo se mantiene para otros valores de cuadros por periodo.
Por ejemplo, si subo a 1024, la latencia total son 2048 frames o (sigo en la frecuencia de 48 kHz) 42,7 ms. Si lanzo ahora jack_delay:
capture latency = 1024
playback_latency = 1024
(signal below threshold hasta que hago las conexiones virtuales entre jack_delay y system)
2107.607 frames 43.908 ms
2107.607 frames 43.908 ms
2107.608 frames 43.909 ms
2107.609 frames 43.909 ms
2107.608 frames 43.909 ms
...
La diferencia, 2108 - 2048 = 60 frames. Se mantiene igual. Es una latencia fija que viene dada por el hardware, que tiene que convertir la señal digital que produce jack_delay a señal analógica a la salida y a través del cable va a la entrada donde se vuelve a convertir a señal digital. jack_delay se las arregla para comparar la señal que emite con la señal que captura y deducir la latencia.
Si con una latencia innecesariamente muy baja no tienes xruns genial. Jack está trabajando muy bien en tu sistema, pero no es necesario forzar.
No es "cuanta menos latencia mejor". Es al revés: Cuanta más latencia, siempre que no la notemos, mejor: menos consumo, mejor respuesta gráfica, menor probabilidad de xruns.
Con respecto a mixxx, ni idea. Has probado con un kernel rt y con rtirq_init, a ver si la cosa mejora? No tendrás alguna configuración mala como la frecuencia de la CPU ondemand, o estará tu hardware un un IRQ más poblado de la cuenta?
Más sobre lo mismo:
http://semicorchux.blogspot.com/2010/05/como-medir-la-latencia-real-del-sistema.html
Saludos, Pablo
, debería de trabajar bien.
