44,1 vs 48 en latencias

No se si este post ira aquí pero bueno siento si me equivoco,
el hecho es que estaba yo pensando sobre estos dos modos de grabación
y haciendo unos cálculos, parece ser, que los tiempos de latencia por sample
son mas cortos cuando usamos 48khz.

EJEMPLOS:

44.1Khz/ 1000samples = 0,022675ms por 1 sample

-----------0,022675ms x 64 = 1,4512 ms
-----------0,022675ms x 128= 2,9024 ms
-----------0,022675ms x 256= 5,9048 ms
etc...

48Khz / 1000samples = 0,020833''ms por 1 sample

-----------0,02083ms x 64 = 1,33312 ms
-----------0,02083ms x 128= 2,66624 ms
-----------0,02083ms x 256= 5,33248 ms

Si nos fijamos en los resultados multiplicando que se obtienen al
multiplicar los ms de latencia por los samples del sistema que
utilizamos nos da que al grabar en ''mas'' ''calidad'' la latencia es mas baja.

aver que opina la gente pues me parece un poco raro
que al trabajar con mas datos la latencia sea menor...
a ver si alguien me corrige o algo...
aunque no se si me habré equivocado
saludos

Tu deducción es correcta. Al muestrear más rápido, un buffer de tamaño constante se llenará antes, generando menos latencia.
Pero esa menor latencia es una ilusión, porque no se elige la latencia, sino el tamaño de buffer para que el sistema sea capaz de atender al procesamiento de datos con cierto margen de seguridad. Por tanto, aumentar la frecuencia de muestreo (Fs) te obligará a aumentar también el tamaño de buffer para compensar, generando la misma latencia que tenías antes.
Sólo en caso de que el tamaño de buffer anterior estuviera sobredimensionado podrás dejarlo constante al aumentar Fs.
Como se ve, la latencia es una consecuencia directa del tamaño de buffer, no al revés. Pero aclaro que estamos hablando de un sólo un tipo de latencia, la generada por el tamaño de buffers de entrada y salida del driver/interfaz.

Supongo que te parecería raro porque muchas herramientas de config de drivers van en contra de la lógica de funcionamiento: te piden seleccionar latencia (#ms) en vez de tamaño de buffer (#samples).

Por otro lado, hay gente que dice que unas interfaces de audio generan más latencia que otras. Eso en general no es cierto salvo que se matice. Lo que puede pasar es que generen más carga o interrupciones indebidas al sistema (por mal diseño hardware o mala programación de drivers), y eso te obligue a aumentar el tamaño de buffer.
La única característica de una tarjeta que se me ocurre que pueda afectar es el tipo de bus, por su latencia mínima inherente: USB 1 ms, Firewire 0.125 ms en modo isócrono, PCIe decenas de nanosegundos.


Como decía antes, hay más latencias al trabajar con digital y no todas son despreciables:
- Latencia de bus de la interfaz -> mejor usar buses serie e internos como PCIe (PCI Express).
- Convertidores AD y DA [1] -> sumando entrada y salida pueden ser hasta 3 ms. Cambian en función de la Fs, porque no compensan los buffers seguramente porque el hardware les limite. Lo cual da que pensar, quizás suene mejor a menor Fs por tener más buffer que permita mejor eliminación de jitter...
- Buffers de entrada y salida del driver [2] -> los comentados en tu post inicial, son de los más grandes, y variables en función de la potencia del sistema.
- Procesamiento de plugins [3] -> algunos son enormes como convolución con impulsos mal recortados. Cuidado con los DAW que no los compensan automáticamente como algunos ProTools.
- Planificación de CPU del S.O. -> las tareas no tienen tiempos deterministas para finalizarse o atenderse, lo ideal sería que los SS.OO. para audio fueran de tiempo real duro, pero Windows y MacOSX no lo tienen, Linux sólo parcheando el kernel. Además, no basta con el soporte del S.O., el software debe estar programado para usarlo y es un tema complejo.
- Aire entre monitores nearfield y oído [4] -> 3 ms a 1 metro.
- Sistemas inalámbricos de micro/instrumento -> cada uno será distinto, pero siempre tendrán mayor latencia que el cable.

1: Cuando se usan distintos convertidores AD para grabaciones multipista, el DAW no tiene forma de saber la latencia de éstos, así que no puede compensarla automáticamente. Lo ideal sería que el formato digital como AES3 tuviera un campo Latency que se la indicara al receptor. Conviene hacerlo a mano (o con plantillas del DAW) tomando las pistas del ADC maestro como referencia para desplazar el resto, o se producirá interferencia indeseable. Por esto también conviene usar el mayor número de ADC en el mismo chasis, con mismo reloj y chips.

2: Si no se necesita procesamiento por software, se puede usar la función "zero latency" de la interfaz de audio. Esto elimina la latencia de buffers de I/O, de bus, de proceso de plugin y de planificación de CPU, pero no la de los conversores si éstos son externos conectados vía digital.

3: Mismo caso que 1, si el DAW no autocompensa la latencia que un plugin le comunica vía VST o el protocolo que sea, se producirá interferencia indeseable.

4: Eliminable con auriculares.


Como ejemplo, pongo una de las estimaciones de latencia que hice recientemente para mi sistema a 44,1 kHz y 64 muestras de buffers, son sumando entrada y salida en una situación de monitorización procesando con software:
*** Lavry M·AD + FW In + interface 64 samples IN + plugin processing + interface 64 samples OUT + FW Out + Lavry M·DA + 1 m desde altavoces
*** 1,375 + 0,125 + 1,451 + 3 (p.ej.) + 1,451 + 0,125 + 1,69 + 2,916 = 12,133 ms

Un saludo.

Uf, que larga la respuesta de Nethox, resumamos, pues si, a mayor frecuencia de muestreo menor la tencia, lo que no implica que tengas menor sobrecarga del CPU. A lo que me refiero es que con el mismo buffer tendras menor latencia si subes la frecuencia, pero quizas necesites un buffer mas grande al subir la frecuencia de muestreo.

En otras palabras, no es la latencia lo que nos importa, lo importante es no sobre cargar el CPU, para que no se sobrecargue y trabaje olgadamente tu induces una latencia, para dejarle tiempo para pensar, por tanto lo que buscas no es tener latencias mas bajas, si no tener la latencia mas baja que puedas para no sobre cargar el CPU y asi evitar chasquidos y cortes, eso dependera de la carga que le des al CPU, si aumentas la frecuencia pues le daras mas carga, por tanto quizas tengas chasquidos y cortes, si, te ira con menor latencia, pero ya sabes que esa lantecia es algo beneficioso, y como todo lo bueno, en exceso se vuelve malo.

bueno gracias pro las respuestas
la verdad yo siempre trabajo a 64 samples y bueno con los pc tan potentes
que hay a dia de hoy...
yo al menos no tengo ninguno tipo de problema con la cpu al trabajar en mi sistema protools.
pero bueno era a nivel de curiosidad el por que lo queria saber,
tampoco creo que se notara apenas la diferencia de latencia entre uno y otro.

de todas formas gracias por la extensa informacion
saludos^^