HTC DriverGate – a versão de áudio

Bem, depois de um dia ou dois de Windows Mobile se sentir bem, voltamos a alguns problemas que estão atormentando desnecessariamente nossos dispositivos.

Parece que o driver está mais uma vez afetando dispositivos HTC selecionados, incluindo todos os dispositivos de geração atual de ponta, como o HTC Touch Diamond, Touch Pro, HD e Xperia. Quando o som é reproduzido através de fones de ouvido ou alto-falantes periodicamente (geralmente uma vez a cada 5 minutos), você ouvirá um pequeno "pulo" no áudio. O som foi descrito como um lag/skip/hiccup/tick/blip. O problema parece estar no driver do dispositivo wave ou possivelmente no próprio dispositivo wave de hardware (Qualcomm em ação novamente?) O problema não parece estar presente no A2DP.

O problema afeta principalmente jogadores de terceiros, pois a HTC parece ter resolvido o problema, mas apenas para si, construindo um driver de onda personalizado.

A equipe do Conduit Pocket Player está investigando o problema e voltou desanimada. Isto é o que tinham a dizer sobre o assunto.

Fizemos testes extensivos sobre o problema de salto de áudio HTC e chegamos à conclusão de que não é algo que os Conduits possam resolver. Depois de analisar o programa HTC Audio Manager e vários outros arquivos (como o DirectShow Audio Renderer HTCRenderFlt2.dll e HTCADXRenderer4.dll da HTC), descobrimos que ambos estão fazendo algumas chamadas de sistema muito especiais no driver WaveOut.

Aqui estão alguns detalhes técnicos para o que encontramos. Primeiro, não achamos que a prioridade de thread ou processo tenha algo a ver com o problema. O aplicativo de áudio normal usa um ciclo de 'buffers waveOut' que mantêm a saída de áudio 'cheia' com dados de áudio para o sistema extrair e reproduzir. Os aplicativos usam funções waveOutWrite padrão para preencher esses buffers. Do ponto de vista do Pocket Player, esses buffers estão sempre cheios, e ajustar as prioridades não afetará isso. Uma maneira de melhorar os saltos de áudio (que afetou o HTC TyTN) era aumentar a prioridade de thread do driver WaveOut editando um valor do Registro em HKLM\Drivers\Builtin\WaveOut. Essa abordagem não funcionou aqui. Curiosamente, esses problemas de salto ocorrem em PCs desktop. Lá, o problema está relacionado a drivers em tempo real que demoram “muito” em seu processamento, o que impede o driver de áudio de processar o próximo lote de som. Isso acontece no Vista com alguns drivers do MacBook.

O Audio Manager usa um mecanismo de saída diferente das chamadas waveOut padrão – ele usa o filtro de renderização de áudio DirectShow, que é outra maneira de enviar áudio. Olhando para dentro de como funciona, está usando um mecanismo completamente diferente. Ele está usando uma chamada proprietária waveOutMessage para abrir uma nova fila de mensagens, pela qual o áudio é então “transmitido”.

O Pocket Player (e outros aplicativos) poderia resolver esse problema usando o HTC Audio Renderer em vez de suas próprias rotinas waveOut, mas perderíamos o crossfading e outros recursos específicos do Pocket Player. Fizemos alguns testes iniciais de criação de um gráfico de filtro DirectShow (completo com seu renderizador de áudio), mas ainda experimentamos o salto, portanto, deve haver etapas adicionais.

Como resultado, a Conduits agora está considerando isso como um problema específico do dispositivo que o fabricante é obrigado a corrigir. Alternativamente, se a HTC quiser documentar seu “modo de streaming” especial para seu driver de saída de áudio, podemos procurar adaptar a esse modelo.

Se você extrair o Wavedev.dll de uma ROM, verá inúmeras mensagens de depuração relacionadas a “MP3 Streams” e similares, indicando um caminho de áudio totalmente separado para música proveniente de seu software. Se necessário, reescreveremos nosso plug-in de saída WaveOut (nossas rotinas de saída usam uma arquitetura de plug-in privada, assim como nossos outros tipos de plug-in) que usa a saída DirectShow.

A HTC se recusou a documentar como eles resolveram o problema, dizendo que não suportava software de terceiros.

É claro que XDA-Developers nunca deixam uma situação como essa de lado. A Thx1200 está iniciando uma recompensa para desenvolvedores que possam produzir uma solução de código aberto para esse problema e disponibilizá-la para a comunidade. Atualmente, a recompensa é de apenas US $ 30, mas tenho certeza de que podemos gerar muito mais doações para resolver esse problema irritante para quem usa um software de áudio de terceiros.

Leia o tópico completo no XDA-Developers aqui, e não se esqueça de adicionar seu compromisso também se você sentir que esta é uma situação que precisa ser corrigida.