¿Con qué precisión (en términos de tiempo) Windows reproduce audio?

Question

Digamos que reproduzco un archivo WAV estéreo con 317,520,000 muestras, que es teóricamente 1 hora de duración. Suponiendo que no haya interrupciones en la reproducción, ¿terminará el archivo en exactamente una hora, o hay alguna pequeña variación ocasional en la velocidad de reproducción de modo que sea un poco más o ligeramente menor (en algunos minutos) que una hora ?

Estoy tratando de sincronizar la animación con el audio, y estoy usando un System.Diagnostics.Stopwatch para mantener los cuadros que coincidan con el audio. Pero si la velocidad de reproducción de audio WAV en Windows puede variar ligeramente con el tiempo, el audio se desviará de sincronización con la animación impulsada por el cronómetro.

Lo que lleva a una segunda pregunta: parece que un Stopwatch - aunque muy granular y preciso para duraciones cortas - se ejecuta un poco rápido. En mi computadora portátil, una ejecución de Stopwatch durante exactamente 24 horas (medida por la hora del sistema de la computadora y un cronómetro real) muestra un tiempo transcurrido de 24 horas más de aproximadamente 5 segundos (no milisegundos).

¿Es este un problema conocido con Stopwatch? (Una pregunta relacionada sería "¿estoy loco?", Pero puedes intentarlo por ti mismo). Dado su uso como una herramienta de diagnóstico, puedo ver dónde una discrepancia como esta solo aparece cuando se miden duraciones largas, para lo cual la mayoría las personas usarían algo distinto de Stopwatch.

Si tengo mucha suerte, tanto la Stopwatch como la reproducción de audio son impulsadas por el mismo mecanismo subyacente y, por lo tanto, permanecerán sincronizados durante días enteros. ¿Hay alguna posibilidad de que esto sea cierto?

actualización: acabo de hacer los cálculos, y si Stopwatch derivas por 5 segundos de más de 24 horas, esto significa que va a la deriva por 10 milisegundos después de tan sólo 172 segundos. Entonces, en 3 minutos, la animación comenzará a estar perceptiblemente fuera de sincronización.

Estoy experimentando periódicamente (cada 10 segundos más o menos) reiniciando el temporizador de la devolución de llamada waveOutWrite, pero esto no está funcionando porque el siguiente conjunto de eventos del temporizador se compensa con la inexactitud del devolución de llamada pasó a ser. Apesta ser yo.

Answer 1

Larry Osterman dio la respuesta en un comentario:

Fwiw, en Windows el reloj de vídeo es impulsado por el reloj de audio. Si eres de audio renderizado, se obtiene el reloj de audio llamando waveOutGetPosition (puesto que el audio está sincronizado, la posición se corrolated directamente con tiempo). Todas las demás API de reproducción de audio tienen una API "GetPosition" similar que se puede usar para determinar la posición de reproducción de audio .

Answer 2

Ningún reloj medirá el tiempo "exactamente", ya que todos los dispositivos físicos tienen algunas variaciones y errores de medición. Esto significa que TODOS los relojes serán demasiado rápidos o demasiado lentos (aunque la cantidad de errores puede diferir enormemente, dependiendo del reloj).

En su caso, la salida de audio se controla con el reloj de la tarjeta de sonido que controla el DAC. No conozco la plataforma .NET, pero asumo que el cronómetro es una especie de temporizador de sistema, lo que significa que es impulsado por un reloj DIFERENTE (el de su placa madre, presumiblemente).

Ahora, en general, dos relojes físicos diferentes NUNCA se ejecutarán exactamente a la misma velocidad, por los motivos descritos anteriormente. De ahí proviene la discrepancia que tienes. Lo mismo sucederá con su animación: puede absolutamente nunca suponer que el reloj del sistema y la tarjeta de sonido del reloj DAC son iguales - ¡serán diferentes!

Esto significa que si desea mantener sincronizadas dos transmisiones (video y audio), deben estar controladas por el mismo reloj. Como no puede cambiar el reloj que impulsa su tarjeta de sonido, es una buena opción sincronizar todo con la tarjeta de sonido.