Componentes de áudio herdados do Windows - Windows legacy audio components

Este artigo descreve APIs de áudio e componentes no Microsoft Windows que agora estão obsoletos ou preteridos.

Extensões Multimídia (MME)

A API MME ou Windows Multimedia API (também conhecida como WinMM ) foi a primeira API de áudio universal e padronizada do Windows. Os eventos de som wave reproduzidos no Windows (até Windows XP ) e MIDI I / O usam MME. Os dispositivos listados no miniaplicativo do painel de controle Multimídia / Sons e Áudio representam a API MME do driver da placa de som .

As extensões multimídia (interfaces WaveIn / WaveOut) foram lançadas no outono de 1991 para oferecer suporte a placas de som , bem como unidades de CD-ROM , que estavam se tornando cada vez mais disponíveis. As extensões de multimídia foram lançadas para fabricantes de equipamento original (OEMs) , principalmente fabricantes de unidade de CD-ROM e placa de som, e adicionou suporte multimídia básico para entrada e saída de áudio e um aplicativo de reprodutor de áudio de CD para o Windows 3.0. Os novos recursos das Extensões de Multimídia não estavam disponíveis no modo real do Windows 3.0, apenas no modo padrão e 386 avançado. O Windows 3.1x posteriormente incorporaria muitos de seus recursos. A Microsoft desenvolveu a especificação da placa de som do Windows Sound System para complementar essas extensões.

No Windows 95 / ME, o MME não mistura vários fluxos de áudio durante a reprodução e o compartilhamento de dispositivo, portanto, apenas um fluxo de áudio pode ser renderizado por vez. Mas alguns drivers de placa de som podem emular mais de um dispositivo MME (ou oferecer suporte a mais de um único cliente de streaming), portanto, também podem funcionar com MME. A partir do Windows 2000, o MME oferece suporte ao compartilhamento de dispositivos de reprodução (acesso multi-cliente) e pode misturar fluxos de reprodução. A partir do Windows XP, o MME passou a oferecer suporte ao compartilhamento de dispositivos de gravação.

Na versão anterior do Windows, o MME suportava até dois canais de gravação, profundidade de bits de áudio de 16 bits e taxas de amostragem de até 44100 amostras por segundo, com todo o áudio sendo mixado e amostrado para 44100 amostras por segundo. A partir do Windows 2000, o MME suporta até 384.000 amostras por segundo, até 8 canais e até 32 bits por amostra.

Antes do Windows XP, o número de interfaces de dispositivo MME / WinMM (waveIn, waveOut, midiIn, midiOut, mixer e aux) era restrito a 10. Esse limite foi aumentado de 10 para 32 no Windows XP.

O comprimento do nome do dispositivo no MME é restrito a 31 caracteres, portanto nomes longos do dispositivo podem aparecer apenas parcialmente.

questões

Uma falha na emulação MME WaveIn / WaveOut foi introduzida no Windows Vista: se a conversão da taxa de amostragem for necessária, o ruído audível às vezes é introduzido, como ao reproduzir áudio em um navegador da Web que usa essas APIs. Isso ocorre porque o reamostrador interno, que não é mais configurável, assume como padrão uma interpolação linear baseada em números inteiros rápida (por exemplo, a nova amostra é tomada como uma duplicata exata da amostra mais próxima em vez de uma porção variável das duas amostras mais próximas), que foi o modo de conversão de qualidade mais baixa que poderia ser definido nas versões anteriores do Windows. O reamostrador pode ser definido para um modo de alta qualidade por meio de um hotfix para Windows 7 e Windows Server 2008 apenas.

Gerenciador de compressão de áudio

O Audio Compression Manager (ACM) é uma estrutura de multimídia do Windows que gerencia codecs de áudio (compactadores / descompressores). ACM também pode ser considerado uma especificação de API. Um codec deve estar em conformidade com a especificação ACM implícita para funcionar com o Windows Multimedia. Os arquivos ACM podem ser reconhecidos por sua extensão de nome de arquivo .acm . Os arquivos ACM também usam tipos de arquivos compatíveis com RIFF , como WAV ou AVI, como um "invólucro" para armazenar dados de áudio codificados por qualquer codec de áudio compatível com ACM.

ACM é considerado um framework / API desatualizado e a Microsoft agora incentiva o uso de pelo menos DirectShow . No entanto, ao contrário do ACM e do Video Compression Manager (VCM) relacionado , o DirectShow não fornece meios para codificar arquivos para usuários finais, mas requer que os desenvolvedores criem gráficos de ponta a ponta para codificar o conteúdo. ACM também não oferece suporte a fluxos de áudio VBR ; portanto, codecs mais novos como MPEG-4 AAC , Ogg Vorbis , FLAC etc. não podem ser suportados por ACM se usar taxas de bits variáveis. Embora muitas fontes afirmem o contrário, Ogg Vorbis funciona bem com o ACM, por exemplo, quando embutido em um arquivo compatível com RIFF (como um arquivo WAV ou AVI como mencionado anteriormente), desde que o fluxo Ogg Vorbis seja codificado em uma taxa de bits constante.

O Windows vem com vários codecs ACM pré-instalados. Para obter uma lista desses codecs, consulte o arquivo WAV § Comparação de esquemas de codificação .

Os codecs ACM são identificados por um código de dois bytes (TwoCC) alocado pela Microsoft.

Bibliotecas de áudio DirectX

KMixer

KMixer é o driver Kernel Audio Mixer , uma parte do WDM Audio do Windows 98 ao Windows XP que lida com a mixagem de vários buffers de som em uma saída.

As tarefas realizadas pelo KMixer.sys:

  • Misturar vários fluxos de áudio PCM
  • Formato, profundidade de bits (também conhecido como comprimento de palavra) e conversão de taxa de amostragem
  • Configuração de alto-falante e mapeamento de canal

No Windows 98, Windows 2000 e Windows Me, a taxa de amostragem máxima do KMixer é 100 kHz. No Windows XP SP1 e posterior, a taxa de amostragem de áudio do KMixer suporta no máximo 200 kHz.

questões

O KMixer foi projetado para auxiliar os aplicativos, dispensando-os da necessidade de realizar a mixagem de fluxos de áudio, especialmente em placas de som simples que não suportavam vários fluxos de som. No entanto, ele introduziu alguns problemas significativos.

Em primeiro lugar, a latência do KMixer é de cerca de 30 ms e não pode ser reduzida, porque este componente fica logo acima do driver de áudio da classe de porta, portanto, todos os fluxos de áudio, incluindo aqueles emitidos por DirectSound (exceto em casos de mixagem de hardware ) e WinMM, vem através do mixer do kernel. Se o hardware de áudio suportar mixagem de hardware (também conhecido como buffer de hardware ou aceleração de hardware DirectSound), o DirectSound armazena diretamente no dispositivo de renderização. Portanto, se os streams DirectSound usam mixagem de hardware , o KMixer é ignorado.

Em versões anteriores, como a versão original do Windows 98, o KMixer tentou misturar todos os formatos de dados que passaram por ele, mesmo aqueles não compatíveis. Isso causou vários problemas com reprodutores de mídia que tentavam passar fluxos de som surround codificados por AC3 através da saída S / PDIF da placa de som para um receptor de home theater externo . Isso foi corrigido com o Windows Me e fornecido como um hotfix para o Windows 98 Second Edition e Windows 2000 SP2. A partir do Windows Me, as APIs waveOut, DirectSound e DirectShow oferecem suporte a formatos não PCM, como AC-3 ou WMA sobre S / PDIF, e os dados não PCM vão diretamente para o driver da classe em vez de passar pelo KMixer.

Uma nova API de modo kernel, Direct Kernel Streaming , também foi introduzida no Windows 98 para contornar o KMixer e evitar problemas associados a ele.

O KMixer não altera o som na maioria dos casos. Além disso, existem muitas maneiras de contornar o KMixer sem a necessidade de um plug-in extra para acessar DirectSound, ASIO , Direct Kernel Streaming ou WASAPI . No Windows XP, por exemplo, o uso de DirectSound (que o Winamp usa por padrão) com um mixer de hardware é uma maneira de contornar o KMixer.

O KMixer foi removido do Windows Vista . Ele foi substituído pelo mecanismo de áudio WASAPI (API de sessão de áudio do Windows) no modo de usuário, que faz parte da arquitetura de áudio renovada . O mecanismo de áudio pode operar no modo compartilhado ou no modo exclusivo . No modo compartilhado, a mixagem ainda ocorre. O áudio PCM pré-misturado é enviado ao driver em um único formato (em termos de taxa de amostragem, profundidade de bits e contagem de canais) que pode ser configurado no painel de controle de Sons. O modo exclusivo WASAPI ignora o mixer, assim como o uso de APIs de áudio de terceiros, como OpenAL ou ASIO , que ainda têm acesso direto ao hardware.

Streaming de kernel

Fluxo de kernel ou fluxo direto de kernel (Direct KS) é uma técnica que oferece suporte ao processamento no modo kernel de dados de fluxo. Ele permite streaming eficiente em tempo real para dispositivos multimídia, como placas de som e placas sintonizadoras de TV . O streaming de kernel permite que um driver de dispositivo crie filtros e pinos semelhantes ao DirectShow no modo kernel , fornecendo acesso ao hardware, comunicação de menor latência e ainda ser usado em um gráfico de filtro DirectShow .

O streaming de kernel foi introduzido no Windows 98. Quando a placa de som usa um driver personalizado para uso com o driver de classe de porta fornecido pelo sistema PortCls.sys ou implementa um mini-driver para uso com o driver de classe de streaming, os aplicativos podem ignorar o KMixer completamente e usar as interfaces de streaming do kernel, em vez de interagir diretamente com o driver de áudio e reduzir a latência. O Windows 98 inclui o primeiro driver de streaming de kernel, Stream.sys. No Windows XP, a Microsoft introduziu outro driver aprimorado de classe de streaming de kernel, AVStream.

Reprodutores de música como JRiver Media Center , JPLAY, foobar2000 , Audirvana Studio e Winamp suportam streaming de kernel . Em comparação com o "método WaveOut" normal no Microsoft Windows , o streaming do kernel requer menos tempo de CPU . Isso ocorre às custas de ignorar o controle de volume do KMixer e do Windows. O streaming do kernel também não permite o compartilhamento de dispositivos, a menos que o driver de áudio do modo kernel ofereça suporte a vários clientes.

Antes do Windows Vista, o Kernel Streaming oferecia apenas um único protocolo de comunicação cliente-para-driver com cadeia de buffer, conforme usado no MME. A partir do Vista, é introduzido o novo protocolo Real-Time Audio ( RT Audio , não confunda com RTAudio codec ), baseado em um único buffer circular . O protocolo de áudio RT é implementado pelo driver de porta WaveRT em portcls.sys. No Vista e nas versões posteriores, o Audio Subsystem oferece suporte a ambos os protocolos para que possa interagir com drivers de áudio novos e antigos. Mas a maioria dos aplicativos de áudio que usam KS oferece suporte a apenas um único protocolo (legado na maioria dos casos), portanto, eles podem se comunicar apenas com um único tipo de drivers de áudio.

Veja também

Referências

links externos

Links quebrados