Componentes de audio heredados de Windows

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 de onda 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 aquel 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 en el modo mejorado 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 múltiples secuencias de audio durante la reproducción y el uso compartido de dispositivos, por lo que solo se puede reproducir una secuencia de audio a la vez. Sin embargo, 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 secuencias 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 frecuencias de muestreo de hasta 44100 muestras por segundo, con todo el audio mezclado y muestreado a 44100 muestras por segundo. 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 auxiliar) estaba restringida a 10. Este límite aumentó de 10 a 32 en Windows XP.

La longitud del nombre del dispositivo en MME está restringida a 31 caracteres, por lo que los nombres largos pueden aparecer solo 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 se puede configurar, utiliza de manera 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 remuestreador se puede configurar en un modo de alta calidad mediante una revisión rápida para Windows 7 y Windows Server 2008 únicamente.

Audio Compression Manager (ACM) es un marco multimedia de Windows que administra los códecs de audio (compresores/descompresores). 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 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 pueden ser compatibles con ACM si se utilizan 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.

• DirectSound
• DirectMusic
• Direct X plugin

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 que realiza KMixer.sys:

• Mezcla múltiples secuencias de audio PCM
• Formato, bit-depth (también conocido como word-length) y conversión de la muestra
• Configuración de altavoces y mapeo de canales

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.

El KMixer fue diseñado para ayudar a las aplicaciones ahorrándoles 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 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. 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 renderización. Por lo tanto, si los flujos de DirectSound utilizan mezcla de hardware, se omite KMixer.

En versiones anteriores, como la versión original de Windows 98, KMixer intentaba mezclar todos los formatos de datos que pasaban por él, incluso aquellos que no admitía. Esto provocó 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 rápida para Windows 98 Second Edition y Windows 2000 SP2. 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 el uso de KMixer y evitar los problemas asociados con él.

KMixer no altera el sonido en la mayoría de los casos. Además, hay muchas formas de evitar KMixer sin 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.

KMixer fue eliminado en Windows Vista. Fue reemplazado por el motor de audio WASAPI (Windows Audio Session API) en modo usuario, que forma parte de la arquitectura de audio renovada. El motor de audio puede funcionar en modo compartido o exclusivo. En el modo compartido, la mezcla sigue realizándose. El audio PCM premezclado se envía al controlador en un único formato (en términos de frecuencia de muestreo, profundidad de bits y número 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 siguen teniendo acceso directo al hardware.

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 brinda acceso al hardware, comunicación con menor latencia y aún se puede usar dentro de un gráfico de filtros DirectShow.

La transmisión por kernel 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 transmisión, las aplicaciones pueden omitir completamente el KMixer y utilizar las interfaces de transmisión por kernel en su lugar para interactuar directamente con el controlador de audio y reducir la latencia. Windows 98 incluye el primer controlador de transmisión por kernel, Stream.sys. En Windows XP, Microsoft introdujo otro controlador de clase de transmisión por kernel 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 costa de omitir el control de volumen de Windows y KMixer. 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 únicamente un único protocolo de comunicación entre el cliente y el controlador con cadena de búfer, como el utilizado en MME. A partir de Vista, se introdujo 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 de audio RT se implementa mediante el controlador de puerto WaveRT en portcls.sys. En Vista y versiones posteriores, el subsistema de audio 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 utilizan KS admiten únicamente un único protocolo (antiguo en la mayoría de los casos), por lo que pueden comunicarse únicamente con un único tipo de controladores de audio.

• WDM audio en Windows 98
• Arquitectura de audio de Windows Vista
• DirectX
• Universal Audio Architecture (UAA)

• Información sobre Kmixer en el sitio web de Microsoft
• KMixer Latency en el sitio web de Microsoft
• MS ACM Drivers(Codecs) Details
• Cómo escribir Microsoft Audio Compression Manager Codec (Installable Driver)
• foobar2000 plug-in — Kernel Streaming plug-in for foobar2000
• Winamp Kernel Streaming Plugin

• Componentes de transmisión
• MME API (WinMM)
• Componentes de streaming de kernel (documentados para la implementación en ReactOS)