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 la 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 la 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 dar soporte a las tarjetas de sonido , así como a las 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 añadieron soporte multimedia básico para entrada y salida de audio y una aplicación de reproducción de audio en 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 mejorado de 386. Windows 3.1x incorporaría más tarde muchas de sus características. Microsoft desarrolló la especificación de tarjeta de sonido Windows Sound System para complementar estas extensiones.
En Windows 95/ME, MME no permite mezclar varios flujos de audio durante la reproducción y el uso compartido de dispositivos, por lo que solo se puede reproducir 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ía funcionar con MME. A partir de Windows 2000, MME admite el uso compartido de dispositivos de reproducción (acceso multicliente) y puede mezclar flujos de reproducción. A partir de Windows XP, MME comenzó a admitir el uso compartido de dispositivos de grabación.
En versiones anteriores de Windows, MME admitía hasta dos canales de grabación, una 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 requerida ] 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 aumentó 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 es posible que los nombres de dispositivos largos solo aparezcan parcialmente.
En Windows Vista se introdujo una falla en la emulación WaveIn/WaveOut de MME: si se necesita una conversión de frecuencia de muestreo, a veces se introduce un 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, tiene como valor predeterminado 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 remuestreador se puede configurar en un modo de alta calidad mediante una revisión rápida para Windows 7 y Windows Server 2008 únicamente. [3] [4]
Audio Compression Manager (ACM) es un marco multimedia de Windows que administra códecs de audio (compresores/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 de archivo .acm. Los archivos ACM también utilizan tipos de archivo compatibles con RIFF, como WAV o AVI, como un "envoltorio" 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 fomenta el uso de al menos DirectShow . Sin embargo, a diferencia de ACM y el Video Compression Manager (VCM) relacionado , DirectShow no proporciona medios para codificar archivos para los usuarios finales, sino que requiere que los desarrolladores creen gráficos de extremo a extremo para codificar 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 pueden ser compatibles con ACM si se usan tasas de bits variables. Aunque muchas fuentes afirman lo contrario, Ogg Vorbis funciona bien con ACM, por ejemplo, cuando se integra en un archivo compatible con RIFF (como un archivo WAV o AVI como se mencionó anteriormente), siempre que la transmisión Ogg Vorbis esté codificada a una tasa de bits constante.
Windows viene con una serie de códecs ACM preinstalados. Para obtener una lista de estos códecs, consulte 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 del mezclador de audio del núcleo , 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 versiones 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 a liberarlas de la necesidad de realizar la mezcla de flujos de audio, especialmente en tarjetas de sonido de gama baja que no admitían múltiples flujos de sonido. Sin embargo, introdujo algunos problemas importantes.
En primer lugar, 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 cada flujo de audio, incluidos los emitidos por DirectSound (excepto en los casos de mezcla de hardware ) y WinMM, pasan por el mezclador del núcleo. [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 los flujos 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 por él, incluso aquellos que no soportaba. Esto 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 una revisión para Windows 98 Segunda Edición y Windows 2000 SP2. [13] A partir de Windows Me, las API waveOut, DirectSound y DirectShow admiten formatos que no sean 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 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 evitar 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 por defecto) con un mezclador de hardware es una forma de evitar KMixer. [9]
KMixer fue eliminado en Windows Vista . Fue reemplazado por el motor de audio WASAPI (Windows Audio Session API) en modo usuario, que es parte de la arquitectura de audio renovada . El motor de audio puede funcionar en modo compartido o modo exclusivo . En el modo compartido, la mezcla aún se lleva a cabo. El audio PCM premezclado se envía al controlador en un solo formato (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 exclusivo WASAPI omite 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 . Kernel Streaming permite que un controlador de dispositivo cree filtros y pines similares a DirectShow en modo kernel , lo que proporciona acceso al hardware, comunicación con menor latencia y aún se puede usar dentro de un gráfico de filtros DirectShow .
El kernel streaming se introdujo en Windows 98. Cuando la tarjeta de sonido utiliza un controlador personalizado para su uso con el controlador de clase de puerto suministrado por el sistema PortCls.sys o implementa un minicontrolador para su uso con el controlador de clase de streaming, las aplicaciones pueden omitir completamente el KMixer y utilizar las interfaces de kernel streaming en su lugar para interactuar directamente con el controlador de audio y reducir la latencia. Windows 98 incluye el primer controlador de kernel streaming, Stream.sys. En Windows XP, Microsoft introdujo otro controlador de clase de kernel streaming mejorado, AVStream.
Los reproductores de música como JRiver Media Center , JPLAY, foobar2000 , Audirvana Studio y Winamp admiten la transmisión por kernel . En comparación con el "método WaveOut" habitual de Microsoft Windows , la transmisión por kernel requiere menos tiempo de CPU . Esto se produce a expensas de omitir KMixer y el control de volumen de Windows. La transmisión por 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 solo un protocolo de comunicación de cliente a controlador con cadena de búfer, como se usa en MME. A partir de Vista, se introduce el 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 RT Audio se implementa mediante el controlador de puerto WaveRT en portcls.sys. En Vista y versiones posteriores, Audio Subsystem admite ambos protocolos, por lo que puede interactuar con controladores de audio tanto antiguos como nuevos. Pero la mayoría de las aplicaciones de audio que usan KS admiten solo un protocolo (antiguo en la mayoría de los casos), por lo que solo pueden comunicarse con un único tipo de controladores de audio.