Por ahí esta lista no tiene mucho que ver... pero como musix tiene kernel rt: Estaba viendo sobre los kernels rt y en algún punto decía que los kernels normales hacen scheduling con frecuencia de 250 Hz, y el linux realtime lo hace con frecuencia de 1000 Hz.... Lo que no entiendo es por qué JACK te deja setear opciones estúpidas, como poner frecuencia de muestreo de 44100 Hz y 16 frames de buffer... si eso va a hacer que necesite hacer algo a 44100/16 Hz... o sea, 2756 Hz... y eso va a hacer xruns, obviamente!. Por otra parte, qué hace exactamente JACK-latencia? Por favor, si alguno me pudiera aclarar estas dudas y decirme si estoy en lo correcto o equivocado, ayudaría mucho. (Y si es para mañana antes de las 2 de la tarde, mejor! :P)
El Jueves, 21 de Agosto de 2008 01:21, trece ocho escribió: | Por ahí esta lista no tiene mucho que ver... pero como musix tiene | kernel rt: Tiene todo que ver! | Estaba viendo sobre los kernels rt y en algún punto decía que los | kernels normales hacen scheduling con frecuencia de 250 Hz, y el | linux realtime lo hace con frecuencia de 1000 Hz.... | Mmm..... disculpa mi ignorancia, no sé si eso tiene relación, sé que hay un aspecto referente a la sincronización MIDI, no sé si tendrá que ver con lo que afirmás. | Lo que no entiendo es por qué JACK te deja setear opciones | estúpidas, como poner frecuencia de muestreo de 44100 Hz y 16 | frames de buffer... si eso va a hacer que necesite hacer algo a | 44100/16 Hz... o sea, 2756 Hz... y eso va a hacer xruns, | obviamente!. No sé | | Por otra parte, qué hace exactamente JACK-latencia? | Cambia la latencia modificando en tiempo real los valores de jackd, sin reiniciar jackd | | Por favor, si alguno me pudiera aclarar estas dudas y decirme si | estoy en lo correcto o equivocado, ayudaría mucho. | (Y si es para mañana antes de las 2 de la tarde, mejor! :P) <marcos> si, eso lo hablamos y explicamos varias veces en las listas de mail :P <marcos> podés manejar los IRQ como si fueran procesos <marcos> corré rtirq status <marcos> y otras cosas también, ahora disculpá pero no tengo tiempo :( <trece_ocho> ta <trece_ocho> si podés me lo explicás por la lista de mail? Porfa <trece_ocho> necesito esa info para mañana antes de las 12 del mediodÃa <trece_ocho> para un tp que estoy haciendo re urgente <marcos> pero, trece_ocho , yo tampoco es que sé tanto <marcos> Holborn, sabe más, por ejemplo <marcos> holborn <[email protected]> <marcos> te aconsejo que te subscribas rápido a la lista de mail, titules: "URGENTE: necesito saber sobre blablabla" De lo que estoy seguro es sobre los IRQ: podés manejarlos como si fueran procesos, eso con kernels no parcheados con parches RT, no lo podés hacer Es decir, que con un kernel rt podés hacer que la placa de sonido tenga la máxima prioridad con respecto a otros dispositivos. Viendo un poco la config de un kernel rt parcheado: cat config-2.6.23-rt1 | grep -i pree # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_BKL=y CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_RCU_BOOST=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_CRITICAL_PREEMPT_TIMING is not set Viendo la config de un kernel rt sin algunos parches cat config-2.6.21 | grep -i pree # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_DEBUG_PREEMPT is not set Yendo a la consecuencia en el usuario, con estos dos kernels con PREEMPT habilitado, te permiten, por ejemplo que si vos estás grabando en Ardour un canal de una máquina de ritmos, ejemplo Hydrogen, y al mismo tiempo un canal con un bajo acústico/eléctrico metido por línea, no quede desfasado. En un kernel sin PREEMPT habilitado, el bajo quedaría quizá unos 90ms atrasado con respecto a la batería: lo hemos probado, y pasó eso, dado que no podés habilitar RT (tiempo real) en Qjackctl (jackd) ¿Se entiende? ¿alguien tiene mejor info? Además de la mayor latencia, en un kernel no RT, se producen más pérdidas de datos (xruns), al menos es lo que he comprobado. Esto está interesante: http://www.osadl.org/Realtime-Preempt-Kernel.kernel-rt.0.html Built-in tools The kernel global variable kernel_preemption is now logical true, # cat /proc/sys/kernel/kernel_preemption 1 or something went completely wrong, otherwise. The built-in latency trace can be used as an overall test to ensure that the system behaves correctly. This function, however, must be initialized before meaningful values can be obtained: # echo 0 >/proc/sys/kernel/preempt_max_latency If the kernel configuration item wakeup latency histogram is enabled, the latency trace is enabled implicitly at boot time. The worst-case latency that was observed since latency tracing was enabled is available in the latency_trace entry of the /proc file system: # cat /proc/latency_trace preemption latency trace v1.1.5 on 2.6.19-1.rt10.0001 -------------------------------------------------------------------- latency: 39 us, #2/2, CPU#0 | (M:rt VP:0, KP:0, SP:1 HP:1 #P:1) ----------------- | task: posix_cpu_timer-3 (uid:0 nice:0 policy:1 rt_prio:99) ----------------- _------=> CPU# / _-----=> irqs-off | / _----=> need-resched || / _---=> hardirq/softirq ||| / _--=> preempt-depth |||| / ||||| delay cmd pid ||||| time | caller \ / ||||| \ | / <...>-3 0...1 39us : __schedule (__schedule) -- Marcos Guglielmetti - www.mastermagazine.info You see things; and you say 'Why?'; But I dream things that never were; and I say 'Why not?' - George Bernard Shaw ======================================================================= Videos, charlas, tutoriales: http://media.ututo.org:14888/Movies/Musix/
participants (2)
-
Marcos Guglielmetti -
trece ocho