Durante meu mandato mantendo a pilha de áudio do PC no Ubuntu, fiz várias apresentações sobre a depuração do aspecto da área de trabalho , e você pode encontrar este o mais gentil ou informativo. A essência da questão é que combinações de ego (também conhecido como "orgulho técnico"), política e colisões de propriedade (também conhecidas como "nenhum mantenedor") causaram um pântano de APIs ao longo da última década (e alguns anos), e muitas suposições incorretas foram feitas em todo o lugar. Continuamos a eliminar muitas das inconsistências e suposições pobres . Para o Ubuntu, especificamente, temos um grupo do Launchpad do desenvolvedor . Eu não posso falar pelos outros membros, porque eles são todos funcionários da Canonical e podem ter restrições adicionais, mas certamente sinta-se à vontade para entrar em contato comigo através do Launchpad; Fico feliz em guiá-lo através do processo de depuração individualmente, conforme nossos esquemas são mesclados.
É absolutamente vital notar que o PulseAudio tem requisitos mais rigorosos do hardware de áudio de uma maneira fundamentalmente diferente dos aplicativos tradicionais . Esses requisitos continuam expondo suposições ruins no kernel, nos drivers de som e nas bibliotecas subjacentes. Por muito tempo, a "solução" das pessoas para "consertar som quebrado" consistiu na remoção do PulseAudio, que efetivamente pula os aspectos quebrados do kernel, os drivers de som e as próprias bibliotecas subjacentes. Então, enquanto você "recupera o som", o problema permanece. No final, é muito melhor corrigir os problemas completamente.
Para resumir, existem duas abordagens gerais para depuração de áudio metódica. Qualquer um começa no nível do aplicativo, digamos, Banshee, ou um começa no nível do hardware. Por uma questão de consistência, vou me referir ao primeiro como "alto nível", ou seja, maior na pilha, e o segundo como "baixo nível", ou menor na pilha mais próxima do hardware. Sinto-me mais à vontade para solucionar problemas desde o nível mais baixo, pois meu envolvimento com áudio na última década (desde a criação e manutenção de drivers até a integração de aplicativos) tem visto OEMs repetindo erros que o Linux, ou seja, o kernel, tem que resolver (ou "hackear" como nós, desenvolvedores, às vezes chamamos). No entanto, as pessoas de hardware não são mais culpadas do que as pessoas de software. Esses problemas têm muitas bases: não importa se estão no BIOS, na fonte de alimentação, nas pontes da placa-mãe, nos controladores de som e codecs, no kernel ou nas partes do espaço do usuário (bibliotecas, APIs, PulseAudio, aplicativos etc. ). No final, a questão é bastante simples: todos nós lidamos de forma insuficiente com as condições fora dos limites de todos os níveis abaixo e através de .
No nível de hardware do PC, começamos a depurar identificando precisamente quais componentes são usados . A maioria dos hardwares de desktop modernos possui duas partes significativas de informações: o identificador do subsistema PCI e o identificador do subsistema de codec de áudio. Você pode encontrar o primeiro via lspci -nv ; procure os códigos de subsistema de áudio 0401 ( AC'97 ) ou 0403 ( Áudio de alta definição ). Dependendo do hardware, este último pode ser identificado através de informações expostas pelo próprio ALSA driver em /proc/asound (o script de depuração dos desenvolvedores que acabei de vincular automatiza grande parte da coleta de informações). É absolutamente vital que se perceba e lembre-se de que sintomas semelhantes, até mesmo idênticos, geralmente têm causas variadas de hardware e software. Por esse motivo, é mais fácil para as pessoas que consertam os bugs terem um relatório de bug claro, e é por isso que no Ubuntu temos ubuntu-bug alsa-base para problemas de driver e ubuntu-bug pulseaudio para problemas de aplicativo. Se você não tem certeza do que está em falta, basta escolher um, ou usar o sintoma de áudio do Ubuntu. Independentemente disso, solicitaremos informações adicionais, conforme necessário.
O PCI SSID é importante, porque é um registro de qual fabricante de computador integra qual conjunto de componentes de áudio em uma placa-mãe. Por exemplo, você encontrará com frequência a Dell, HP / Compaq, Acer, Samsung, Lenovo e assim por diante, usando diferentes combinações de componentes de áudio IDT / Sigmatel, Realtek, Cirrus, Analog e Conexant. Um Dell que tem um Realtek 269 não tem necessariamente o mesmo comportamento que um HP com um Realtek 269 .
O codec SSID pode ser considerado o análogo do PCI da perspectiva do fabricante do equipamento de áudio. As informações associadas ao codec SSID podem ser usadas para descobrir qual revisão foi integrada ao silício.
Infelizmente, aqui é onde os problemas começam. Assumindo que o BIOS esteja ok (o que é uma suposição bastante cega, já que há muitos BIOSes quebrados que causam estragos no áudio do Linux), algumas vezes o SSID PCI é reutilizado incorretamente. Nessas situações, nosso recurso é aplicar peculiaridades específicas no driver com base no codec SSID. Infelizmente ainda, às vezes o codec SSID é reutilizado incorretamente. Nessas situações, temos que observar revisões específicas do codec, além de tentativas mais cegas de forçar a reinicialização do driver.
Para a maioria dos equipamentos mais novos, tendemos a confiar no BIOS em vez de usar nossa abordagem histórica de "apenas use esta definição codificada". Em algumas situações, temos que usar ferramentas para emular o codec para descobrir quais definições de pinos executam quais funções. Funções ausentes no driver para manipular o sentido da tomada, ou seja, (des) silenciar os alto-falantes internos quando os fones de ouvido são (removidos) inseridos, pode ser facilmente corrigido dessa maneira.
Após determinarmos que o hardware subjacente não está quebrado e que o driver de som não precisa ser corrigido, analisamos a camada do espaço do usuário, ou seja, alsa-lib , alsa-plugins e pulseaudio . A grande maioria dos problemas está no driver ou em (alguma interface para) o PulseAudio.
alsa-lib é responsável por manipular todas as operações nativas do ALSA (assim, o PulseAudio também o utiliza). Problemas aqui irão se manifestar independentemente do uso do PulseAudio. Por outro lado, os problemas que surgem apenas quando o dispositivo virtual ALSA 'padrão' é usado podem apontar para o plug-in PulseAudio alsa-lib (em alsa-plugins ) ou para o próprio PulseAudio. Nas instalações padrão do Ubuntu 8.10 e do Kubuntu 10.10, rotas 'padrão' através do PulseAudio, então alternar entre as saídas padrão e nativas do PulseAudio (ou entradas como o caso de uso pode ser) deve ajudar a diminuir qual camada investigar mais profundamente. >