Comment comprendre le sous-système audio?
J'ai déjà utilisé beaucoup de versions d'Ubuntu, j'ai commencé avec 5.10. Mais depuis que j'ai eu des problèmes avec le sous-système audio. Quel que soit le matériel, j'ai actuellement deux ordinateurs et les deux ont des problèmes. Sur mon ordinateur portable, je dois déclencher le canal du haut-parleur pour obtenir du son, sur mon bureau, également Ubuntu 10.04/32 bits, il m'a fallu aussi beaucoup de tripotage pour que le son fonctionne. En fait, cela a simplement fonctionné par accident. Bien que la qualité du son d'entrée soit toujours vraiment mauvaise.
Maintenant, j'ai installé sur une autre partition Ubuntu 10.04/64bit et le son ne fonctionne pas bien que la pile logicielle de haut niveau semble bien. Pavucontrol enregistre les sons et montre le bon matériel mais je n'entends rien. (Sauf sur les autres prises de sortie, le panneau avant et l'autre canal, j'entends des sons étranges.)
Ma question est: comment puis-je apprendre à comprendre le système sonore d'Ubuntu et être capable de déboguer de tels problèmes moi-même?
Et une autre question: pourquoi l'audio sur Ubuntu est-il si compliqué? Il doit y avoir des dizaines de milliers de discussions dans les forums en ligne sur ces problèmes et j'ai déjà vu des dizaines de discussions n'indiquant aucune solution réussie. D'un autre côté, il doit y avoir des centaines de guides de résolution de problèmes, mais aucun d'eux n'est capable de couvrir tout cela ...
Merci, Philip
Pendant mon mandat de maintenance de la pile audio PC dans Ubuntu, j'ai fait plusieurs présentations sur le débogage de l'aspect burea , et vous pouvez trouver celui-ci le plus doux ou informatif. L'essentiel de la question est que des combinaisons d'ego (alias "fierté technique"), de politique et de collisions entre propriétaires (alias "aucun mainteneur") ont provoqué un bourbier d'API au cours de la dernière décennie (et de quelques années), et de nombreuses hypothèses incorrectes ont été émises partout. Nous continuons d'éliminer bon nombre des incohérences et des mauvaises hypothèses. Pour Ubuntu en particulier, nous avons un groupe Launchpad développeur . Je ne peux pas parler au nom des autres membres, car ils sont tous des employés de Canonical et peuvent avoir des restrictions supplémentaires, mais n'hésitez pas à me contacter via Launchpad; Je suis heureux de vous guider à travers le processus de débogage individuellement pendant que nos horaires s'enchaînent.
Il est absolument vital de noter que PulseAudio a des exigences plus strictes de son matériel audio d'une manière fondamentalement différente des applications traditionnelles. Ces exigences continuent d'exposer de mauvaises hypothèses dans le noyau, les pilotes audio et les bibliothèques sous-jacentes. Pendant longtemps, la "solution" populaire pour "réparer le son cassé" a consisté à supprimer PulseAudio, qui ignore efficacement les aspects cassés du noyau, les pilotes de son et les bibliothèques sous-jacentes elles-mêmes. Ainsi, pendant que vous "récupérez le son", le problème demeure. En fin de compte, il est préférable de résoudre complètement les problèmes.
Pour résumer, il existe deux approches générales pour le débogage audio méthodique. Soit on commence au niveau de l'application, disons, Banshee, soit on commence au niveau matériel. Par souci de cohérence, je qualifierai le premier de "haut niveau", c'est-à-dire plus haut dans la pile, et le second de "bas niveau", ou plus bas dans la pile la plus proche du matériel. Je suis plus à l'aise pour résoudre les problèmes du niveau le plus bas, car mon implication dans l'audio au cours de la dernière décennie (de la création et de la maintenance des pilotes de périphériques à l'intégration des applications) a vu les OEM répéter des erreurs que Linux, c'est-à-dire le noyau, doit contourner. (ou "hack around" comme nous les appelons parfois les développeurs). Pourtant, les gens du matériel ne sont pas plus coupables que ceux du logiciel. Ces problèmes ont de nombreuses bases: peu importe qu'ils se trouvent dans le BIOS, l'alimentation, les ponts de la carte mère, les contrôleurs de son et les codecs, le noyau ou les parties de l'espace utilisateur (bibliothèques, API, PulseAudio, applications, etc.) ). En fin de compte, le problème est assez simple: nous gérons tous insuffisamment les conditions hors limites de tous les niveaux inférieurs et supérieurs.
Au niveau du matériel PC, nous commençons le débogage par identifiant précisément quels composants sont utilisés . La plupart des matériels audio de bureau modernes contiennent deux informations importantes: l'identifiant de sous-système PCI et l'identifiant de sous-système de codec audio. Vous pouvez trouver l'ancien via lspci -nv; recherchez les codes de sous-système audio 0401 ( AC'97 ) ou 0403 ( Audio haute définition ). Selon le matériel, ce dernier peut être identifié grâce aux informations exposées par le pilote ALSA lui-même dans /proc/asound (le script de débogage des développeurs que je viens de relier automatise une grande partie de la collecte d'informations). Il est absolument vital de réaliser et de se rappeler que des symptômes similaires, voire identiques, ont souvent des causes matérielles et logicielles différentes. Pour cette raison, il est plus facile pour les personnes corrigeant les bogues d'avoir un rapport de bogue clair, et c'est pourquoi dans Ubuntu, nous avons ubuntu-bug alsa-base pour les problèmes de pilote et ubuntu-bug pulseaudio pour les problèmes d'application. Si vous n'êtes pas sûr de ce qui est en cause, choisissez-en un ou utilisez le symptôme audio d'ubuntu-bug. Quoi qu'il en soit, nous demanderons des informations supplémentaires si nécessaire.
Le SSID PCI est important, car c'est un enregistrement du fabricant de l'ordinateur qui intègre quel ensemble de composants audio sur une carte mère. Par exemple, vous trouverez souvent Dell, HP/Compaq, Acer, Samsung, Lenovo, etc., utilisant différentes combinaisons de composants audio IDT/Sigmatel, Realtek, Cirrus, Analog et Conexant. Un Dell qui a un Realtek 269 n'a pas nécessairement le même comportement qu'un HP avec un Realtek 269.
Le codec SSID peut être considéré comme l'analogue du PCI du point de vue du fabricant d'équipement audio. Les informations associées au codec SSID peuvent être utilisées pour trouver quelle révision a été intégrée au silicium.
Malheureusement, voici où les problèmes commencent. En supposant que le BIOS est correct (ce qui est une hypothèse plutôt aveugle, car il y a beaucoup de BIOS cassés qui font des ravages avec l'audio Linux), le PCI SSID est parfois réutilisé de manière incorrecte. Dans ces situations, notre recours consiste à appliquer des bizarreries spécifiques dans le pilote sur la base du codec SSID. Malheureusement, le SSID du codec est parfois mal réutilisé. Dans ces situations, nous devons examiner des révisions spécifiques du codec en plus des tentatives de forçage brutal plus aveugle pour réinitialiser le pilote.
Pour la plupart des équipements les plus récents, nous avons tendance à faire confiance au BIOS au lieu d'utiliser notre approche historique "il suffit d'utiliser cette définition codée en dur". Dans certaines situations, nous devons utiliser des outils pour émuler le codec pour trouver quelles définitions de broches remplissent quelles fonctions. Fonctions manquantes dans le pilote pour gérer le sens de la prise, c'est-à-dire, désactiver (désactiver) les haut-parleurs internes lorsque le casque est (retiré) inséré, peut être facilement corrigé de cette manière.
Une fois que nous avons déterminé que votre matériel sous-jacent n'est pas endommagé et que le pilote audio n'a pas besoin d'être corrigé, nous examinons la couche d'espace utilisateur, à savoir alsa-lib, alsa-plugins et pulseaudio. La grande majorité des problèmes réside dans le pilote ou dans (une interface vers) PulseAudio.
alsa-lib est responsable de la gestion de toutes les opérations ALSA natives (donc PulseAudio l'utilise également). Les problèmes se manifesteront ici, que PulseAudio soit utilisé ou non. D'un autre côté, les problèmes qui surviennent uniquement lorsque le périphérique virtuel ALSA "par défaut" est utilisé peuvent pointer vers PulseAudio alsa-lib plugin (dans alsa-plugins) ou à PulseAudio lui-même. Dans les installations standard d'Ubuntu 8.10 et Kubuntu 10.10, les itinéraires `` par défaut '' via PulseAudio, donc le basculement entre les sorties PulseAudio `` par défaut '' et natives (ou les entrées selon le cas) devrait aider à affiner la couche à approfondir.
Vous voudrez peut-être commencer à lire à partir de l'entrée PulseAudio sur wiki d'ubunt .