Este artículo describe las API y los componentes de audio de Microsoft Windows que ahora están obsoletos o en desuso.
La API MME o API multimedia de Windows (también conocida como WinMM ) fue la primera API de audio universal y estandarizada de Windows. Los eventos de sonido Wave reproducidos en Windows (hasta Windows XP ) y E/S MIDI utilizan MME. Los dispositivos enumerados en el subprograma del panel de control Multimedia/Sonidos y audio representan la API MME del controlador de la tarjeta de sonido .
Las extensiones multimedia (interfaces WaveIn/WaveOut) se lanzaron en otoño de 1991 para admitir tarjetas de sonido , así como unidades de CD-ROM , que en ese momento estaban cada vez más disponibles. Las Extensiones Multimedia se lanzaron a los Fabricantes de Equipos Originales (OEM) , principalmente fabricantes de unidades de CD-ROM y tarjetas de sonido, y agregaron soporte multimedia básico para entrada y salida de audio y una aplicación de reproductor de audio de CD a Windows 3.0. Las nuevas características de las Extensiones Multimedia no estaban disponibles en el modo real de Windows 3.0, sólo en el modo estándar y 386 mejorado. Windows 3.1x incorporaría posteriormente muchas de sus características. Microsoft desarrolló la especificación de la tarjeta de sonido Windows Sound System para complementar estas extensiones.
En Windows 95/ME, MME carece de mezclar múltiples flujos de audio durante la reproducción y el uso compartido de dispositivos, por lo que sólo se puede procesar un flujo de audio a la vez. Pero algunos controladores de tarjetas de sonido pueden emular más de un dispositivo MME (o admitir más de un cliente de transmisión), por lo que también podrían funcionar con MME. A partir de Windows 2000, MME admite el uso compartido de dispositivos de reproducción (acceso multicliente) y puede mezclar secuencias de reproducción. A partir de Windows XP, MME comenzó a admitir el uso compartido de dispositivos de grabación.
En una versión anterior de Windows, MME admitía hasta dos canales de grabación, profundidad de bits de audio de 16 bits y velocidades de muestreo de hasta 44100 muestras por segundo, con todo el audio mezclado y muestreado a 44100 muestras por segundo. [ cita necesaria ] A partir de Windows 2000, MME admite hasta 384000 muestras por segundo, hasta 8 canales y hasta 32 bits por muestra.
Antes de Windows XP, la cantidad de interfaces de dispositivos MME/WinMM (waveIn, waveOut, midiIn, midiOut, mezclador y aux) estaba restringida a 10. Este límite se eleva de 10 a 32 en Windows XP. [1] [2]
La longitud del nombre del dispositivo en MME está restringida a 31 caracteres, por lo que los nombres largos de los dispositivos pueden aparecer solo parcialmente.
Se introdujo una falla en la emulación MME WaveIn/WaveOut en Windows Vista: si se necesita una conversión de frecuencia de muestreo, a veces se introduce ruido audible, como cuando se reproduce audio en un navegador web que utiliza estas API. Esto se debe a que el remuestreador interno, que ya no es configurable, utiliza de forma predeterminada una interpolación lineal rápida basada en números enteros , que era el modo de conversión de menor calidad que se podía configurar en versiones anteriores de Windows. El resampler se puede configurar en modo de alta calidad mediante una revisión solo para Windows 7 y Windows Server 2008. [3] [4]
Audio Compression Manager (ACM) es un marco multimedia de Windows que gestiona códecs de audio (compresor/descompresores). [5] ACM también puede considerarse una especificación API. Un códec debe cumplir con la especificación ACM implícita para funcionar con Windows Multimedia. Los archivos ACM se pueden reconocer por su extensión de nombre .acm. Los archivos ACM también utilizan tipos de archivos compatibles con RIFF , como WAV o AVI, como "contenedor" para almacenar datos de audio codificados por cualquier códec de audio compatible con ACM.
ACM se considera un marco/API obsoleto y Microsoft ahora recomienda el uso de al menos DirectShow . Sin embargo, a diferencia de ACM y el Administrador de compresión de video (VCM) relacionado , DirectShow no proporciona ningún medio para codificar archivos para los usuarios finales, pero requiere que los desarrolladores creen gráficos de un extremo a otro para codificar el contenido. ACM tampoco admite transmisiones de audio VBR ; por lo tanto, los códecs más nuevos como MPEG-4 AAC , Ogg Vorbis , FLAC , etc. no se pueden admitir a través de ACM si se utilizan velocidades de bits variables. Aunque muchas fuentes afirman lo contrario, Ogg Vorbis funciona bien con ACM, por ejemplo, cuando se incrusta en un archivo compatible con RIFF (como un archivo WAV o AVI como se mencionó anteriormente), siempre que la secuencia de Ogg Vorbis esté codificada a una tasa de bits constante.
Windows viene con varios códecs ACM preinstalados. Para obtener una lista de estos códecs, consulte el archivo WAV § Comparación de esquemas de codificación .
Los códecs ACM se identifican mediante un código de dos bytes (TwoCC) asignado por Microsoft.
KMixer es el controlador Kernel Audio Mixer , una parte de WDM Audio en Windows 98 a Windows XP que maneja la mezcla de múltiples buffers de sonido en una salida.
Las tareas realizadas por KMixer.sys:
En Windows 98, Windows 2000 y Windows Me, la frecuencia de muestreo máxima de KMixer es de 100 kHz. En Windows XP SP1 y posteriores, la frecuencia de muestreo de audio de KMixer admite un máximo de 200 kHz. [6] [7] [8]
El KMixer fue diseñado para ayudar a las aplicaciones liberándolas de la necesidad de realizar la mezcla de transmisiones de audio, especialmente en tarjetas de sonido de gama baja que no admitían múltiples transmisiones de sonido. Sin embargo, introdujo algunos problemas importantes.
Primero, la latencia de KMixer es de alrededor de 30 ms [9] y no se puede reducir, porque este componente se encuentra justo encima del controlador de audio de clase de puerto, por lo que todas las transmisiones de audio, incluidas las emitidas por DirectSound (excepto en casos de mezcla de hardware ) y WinMM, pasan por el mezclador del kernel. [10] Si el hardware de audio admite la mezcla de hardware (también conocida como almacenamiento en búfer de hardware o aceleración de hardware de DirectSound), DirectSound almacena en búfer directamente en el dispositivo de renderizado. [11] Por lo tanto, si las transmisiones de DirectSound utilizan mezcla de hardware , se omite KMixer. [12]
En versiones anteriores, como la versión original de Windows 98, KMixer intentó mezclar todos los formatos de datos que pasaban, incluso aquellos que no admitía. Causó varios problemas con los reproductores multimedia que intentaban pasar secuencias de sonido envolvente codificadas en AC3 a través de la salida S/PDIF de la tarjeta de sonido a un receptor de cine en casa externo . Esto se corrigió con Windows Me y se proporcionó como revisión para Windows 98 Second Edition y Windows 2000 SP2. [13] A partir de Windows Me, las API waveOut, DirectSound y DirectShow admiten formatos que no son PCM, como AC-3 o WMA sobre S/PDIF, y los datos que no son PCM van directamente al controlador de clase en lugar de pasar por KMixer.
También se introdujo en Windows 98 una nueva API en modo kernel, Direct Kernel Streaming , para evitar el KMixer y evitar problemas asociados con él.
KMixer no altera el sonido en la mayoría de los casos. [6] Además, hay muchas formas de omitir KMixer sin la necesidad de un complemento adicional para acceder a DirectSound, ASIO , Direct Kernel Streaming o WASAPI . En Windows XP, por ejemplo, el uso de DirectSound (que Winamp usa de forma predeterminada) con un mezclador de hardware es una forma de evitar KMixer. [9]
KMixer fue eliminado en Windows Vista . Se reemplaza por el motor de audio WASAPI (Windows Audio Session API) en modo de usuario, que forma parte de la arquitectura de audio renovada . El motor de audio puede funcionar en modo compartido o modo exclusivo . En el modo compartido, todavía se produce la mezcla. El audio PCM premezclado se envía al controlador en un formato único (en términos de frecuencia de muestreo, profundidad de bits y recuento de canales) que se puede configurar desde el panel de control de Sonidos. El modo WASAPI Exclusive pasa por alto el mezclador, al igual que el uso de API de audio de terceros como OpenAL o ASIO , que aún tienen acceso directo al hardware. [14]
Kernel Streaming o Direct Kernel streaming (Direct KS) es una técnica que admite el procesamiento en modo kernel de datos transmitidos. Permite una transmisión eficiente en tiempo real para dispositivos multimedia como tarjetas de sonido y tarjetas sintonizadoras de TV . La transmisión del kernel permite que un controlador de dispositivo cree filtros y pines similares a DirectShow en modo kernel , proporcionando acceso al hardware, menor latencia de comunicación y aún se puede utilizar dentro de un gráfico de filtro DirectShow .
La transmisión de kernel se introdujo en Windows 98. Cuando la tarjeta de sonido usa un controlador personalizado para usar con el controlador de clase de puerto PortCls.sys suministrado por el sistema o implementa un minicontrolador para usar con el controlador de clase de transmisión, las aplicaciones pueden omitir el KMixer por completo y usar las interfaces de transmisión del kernel interactúan directamente con el controlador de audio y reducen la latencia. Windows 98 incluye el primer controlador de transmisión del kernel, Stream.sys. En Windows XP, Microsoft introdujo otro controlador de clase de transmisión de kernel mejorado, AVStream.
Los reproductores de música como JRiver Media Center , JPLAY, foobar2000 , Audirvana Studio y Winamp admiten la transmisión del kernel . En comparación con el "método WaveOut" habitual en Microsoft Windows , la transmisión del kernel requiere menos tiempo de CPU . Esto se produce a expensas de omitir el control de volumen de KMixer y Windows. La transmisión del kernel tampoco permite compartir dispositivos a menos que el controlador de audio en modo kernel admita varios clientes.
Antes de Windows Vista, Kernel Streaming ofrecía sólo un único protocolo de comunicación de cliente a controlador con cadena de búfer, como se utiliza en MME. A partir de Vista, se introduce un nuevo protocolo de audio en tiempo real ( RT Audio , que no debe confundirse con el códec RTAudio ), basado en un único búfer circular . El protocolo de audio RT se implementa mediante el controlador del puerto WaveRT en portcls.sys. En Vista y versiones posteriores, Audio Subsystem admite ambos protocolos para que pueda interactuar con controladores de audio nuevos y heredados. Pero la mayoría de las aplicaciones de audio que utilizan KS solo admiten un único protocolo (heredado en la mayoría de los casos), por lo que solo pueden comunicarse con un único tipo de controladores de audio.