SDB:Dépannage audio
Testé sur openSUSE
Articles recommandés
Sommaire
- 1 Général
- 2 Cause
- 3 PulseAudio Volume Control
- 4 aperçu ALSA
- 5 ÉTAPE-1 : Comment tester votre son
- 6 ÉTAPE-2 : Essayer YaST pour configurer son propre son
- 7 ÉTAPE-3 : Vérification de votre configuration audio pour obtenir des informations détaillées
- 8 ETAPE-4 : Mise à jour d'alsa dans openSUSE
- 9 Étape-5: Ajouter le “modèle” de la carte son au fichier /etc/modprobe.d/<file>
- 10 ÉTAPE-6 : Comment résoudre un problème de permissions
- 11 ÉTAPE 7 : Problèmes de PulseAudio
- 12 ÉTAPE-8 : Problèmes audio du phonon KDE4
- 13 ÉTAPE-9 : Déterminer l'ordre des dispositifs sonores
- 14 Configuration du microphone
- 15 Configuration d'un casque Bluetooth
- 16 Configuration du casque d'écoute USB
- 17 Configuration des touches multimédia d'un ordinateur portable
- 18 Déterminer quelle application utilise un dispositif sonore
- 19 Documentation du pilote ALSA
- 20 Un peu de magie
Général
Toutes les étapes de ce guide de dépannage ne seront pas nécessaires. Il vous suffit de passer de l'étape 1 jusqu'à la fin, en vous arrêtant lorsque votre audio commence à fonctionner.
Ce guide est rédigé de façon générique. Il a une plus grande probabilité d'aider un utilisateur s'il ne s'écarte pas des pilotes empaquetés par openSUSE ; bureau et noyau. En d'autres termes, si l'on installe un noyau personnalisé ou des mises à jour vers une version de KDE factory (au lieu de rester avec la version officielle de KDE), ou si on applique un pilote audio fourni par le fabricant, il y a une probabilité accrue que ce guide ne soit d'aucune utilité.
Cause
Après l'installation d'openSUSE, dans certains cas, il est nécessaire d'ajuster les paramètres audio afin d'obtenir du son. Pour certains codecs audio, le RPM "alsa-firmware" (qui n'est pas installé par défaut) est nécessaire pour fournir la fonctionnalité son. Dans les autres cas où le matériel audio est plus récent, une version plus à jour d'ALSA est nécessaire. En raison du très grand nombre de cartes audio sur le marché, YaST peut parfois ne pas être en mesure de configurer la carte automatiquement, et donc la configuration manuelle est nécessaire.
PulseAudio Volume Control
Depuis openSUSE 11.4, KDE a PulseAudio installé et actif par défaut. Gnome avait déjà été doté de PulseAudio auparavant. Dans un tel cas, il peut être utile pour les utilisateurs de KDE d'installer l'application PulseAudio Volume Control (pavucontrol) et d'utiliser cette application pour accorder son audio pour chaque application multimédia. Les utilisateurs de Gnome peuvent trouver pavucontrol déjà installé par défaut. Les utilisateurs de LXDE devront d'abord installer PulseAudio (car PulseAudio n'a pas été installé automatiquement dans LXDE depuis openSUSE 12.1 et les versions antérieures), et ensuite installer pavucontrol.
Pour installer pavucontrol sur openSUSE version 11.4 et ultérieures, tapez "su -" (sans guillemets) suivi du mot de passe root pour obtenir les permissions root dans un terminal konsole/xterm. Ensuite, pour installer pavucontrol, tapez :
zypper in pavucontrol
Une fois installé, tapez "exit" ou appuyez sur CTRL+D pour fermer la session root. Ensuite, pour lancer pavucontrol, tapez "pavucontrol". La première fois que vous exécutez chaque application, réglez PulseAudio pour cette application, en vous assurant que chaque application est réglée pour utiliser le bon périphérique audio.
aperçu ALSA
Notez qu'openSUSE est livré avec ALSA (Advanced Linux Sound Architecture), qui est également installé par défaut. Les utilisateurs ont la possibilité de le configurer pendant l'installation d'openSUSE.
Installation du firmware alsa sur openSUSE-10.3 à 11.2.
A partir d'openSUSE 10.3, certaines des anciennes cartes son nécessitent également le paquet "alsa-firmware" en plus de "alsa" et "alsa-utils". Ainsi, avant de procéder, assurez-vous d'avoir installé "alsa", "alsa-utils", et "alsa-firmware". Il semble que l'installation du progiciel alsa-firmware peut aider les utilisateurs avec : asihpi (dspxxxxxx), ea (gina, indigo, layla, mona), emagic (emi), ess (maestro), mixart, multiface, pcxhr, sb16, vx, yamaha, et quelques autres chipsets.
Pour voir si vous avez le firmware alsa installé, tapez dans une konsole/xterm :
rpm -q alsa alsa alsa-utils alsa-firmware
et si le retour est :
alsa-1.0.14-31.2 alsa-utils-1.0.14-27 package alsa-firmware is not installed
alors alsa-firmware n'est pas installé. Il est utile pour les utilisateurs d'openSUSE 10.3 - et peut-être essentiel pour certains codecs matériels - de l'installer maintenant. Pour les autres versions d'openSUSE, les versions ALSA seront légèrement différentes.
Pour installer alsa-firmware dans openSUSE-10.3-11.2, tapez "su" (sans guillemets) suivi du mot de passe root pour obtenir les permissions root dans cette konsole/xterm, puis pour installer alsa-firmware tapez :
zypper in alsa-firmware
Après l'installation du firmware alsa, redémarrez votre machine, ou assurez-vous que les modules audio du noyau sont rechargés, car rcalsasound ne le fera pas lui-même. Vérifiez votre son (voir ÉTAPE-1 ci-dessous), et si nécessaire, lancez le service ALSA avec la commande ci-dessous, tapez un konsole/xterm :
rcalsasound start
ÉTAPE-1 : Comment tester votre son
Un test simple pour voir si votre son fonctionne, est d'ouvrir une console ou un xterm, et de taper ou copier-coller :
speaker-test -Dplug:front -c2 -l5 -twav
Notez que Linux est sensible à la casse, et "D" n'est pas la même chose que "d". Pendant que la konsole/xterm a le focus de la souris, appuyez sur CTRL-C pour arrêter le test. Notez que vous devez vérifier vos réglages mixer (alsamixer dans le terminal, bien que des programmes graphiques comme kmix puissent également être utilisés) pour vous assurer que PCM et Master Volume ne sont pas mis en sourdine. Si nécessaire, augmentez les niveaux sonores et réessayez jusqu'à ce que vous entendiez le son. Notez que le test pour le son surround est différent.
Si ce test donne des erreurs, essayez plutôt ce test plus simple :
speaker-test -c2 -l5 -twav
S'il n'y a pas de son de l'un ou l'autre des tests lors de l'utilisation d'une konsole (ou xterm) comme utilisateur régulier, essayez comme utilisateur root, c'est-à-dire tapez su -
, puis essayez la ligne de test. Si vous obtenez du son avec les permissions root, mais que vous n'avez pas de son en tant qu'utilisateur régulier, alors vous avez probablement un problème de permissions. Voir ci-dessous à l'étape 6 pour savoir comment traiter cette question. En supposant que vous n'avez aucun son, passez à l'étape 2 ci-dessous.
Suggestions du site Web d'ALSA pour tester le son
Le projet alsa propose également quelques suggestions pour tester son propre son, qui se trouvent ici : http://www.alsa-project.org/main/index.php/SoundcardTesting
ÉTAPE-2 : Essayer YaST pour configurer son propre son
- Essayez de configurer votre son avec YaST (notez que dès que vous avez du son, ne passez pas à l'élément suivant, mais plutôt quittez et appréciez votre son). Pour configurer votre son, allez à :
YAST > Matériel > Son > Autre > Lancer le son de test
et testez votre son. Si vous n'avez pas de son, alors, -
YAST > Matériel > Son > Autre > Volume
et déplacez votre volume PCM et Maitre jusqu'à environ 75% et testez votre son. Si vous n'avez pas de son, alors, -
YAST > Matériel > Son
et sélectionnez votre carte audio et supprimez-la (ce qui efface la configuration, pas la carte). Si vous souhaitez vous assurer que la configuration sonore est complètement supprimée, vous devrez supprimer le fichier /etc/modprobe.d/50-sound.conf (avec les permissions root). Ajoutez ensuite la carte, et configurez la carte. Cela recréera le fichier 50-sound.conf. Testez votre son. Si vous n'avez pas de son alors fermez YaST et - sur openSUSE-11.1 ou une version antérieure, dans une console/externe avec les permissions root (tapez "
su
" (sans guillemets) suivi du mot de passe root pour obtenir les permissions root) tapez :
alsaconf
et configurez votre son. N'essayez PAS ceci sur openSUSE-11.2. Après la configuration, testez votre son, et n'oubliez pas de vérifier votre mixers (kmix ou alsamixer selon le cas).
S'il n'y a toujours pas de son, passez à l'étape 3.
ÉTAPE-3 : Vérification de votre configuration audio pour obtenir des informations détaillées
Il est souvent utile d'en savoir plus sur votre configuration sonore avant de continuer.
Commandes de base dans une konsole/xterm
Pour trouver votre version d'alsa, dans une konsole/xterm tapez :
cat /proc/asound/version
Pour trouver quel(s) module(s) sonore(s) vous avez chargé(s), dans une konsole/xterm tapez :
cat /proc/asound/modules
Pour déterminer le codec audio utilisé par votre carte son (et c'est important), dans une konsole/xterm, tapez :
cat /proc/asound/cards
et cherchez votre codec audio. Par exemple, si vous avez obtenu :
0[nForce2 ] : NFORCE - NVidia nForce2 NVidia nForce2 avec ALC650F à irq 18
Alors pour cet exemple, nous nous intéressons à l'ALC650.
Script à exécuter pour obtenir des informations détaillées
Si cela ne fournit pas le codec, alors une autre approche pour obtenir plus d'informations sur votre matériel et votre configuration sonore, est d'exécuter le script suivant.
Première méthode pour exécuter le script
Le script de diagnostic est celui créé par l'utilisateur wishie d'IRC #alsa. Pour les utilisateurs avec 1.0.17 d'alsa ou plus récent, il est inclus avec alsa. Pour l’exécuter, copiez et collez la ligne ci-dessous avec les permissions root :
/usr/sbin/alsa-info.sh
Souvent, la première fois que vous exécutez ce script, il note qu'une mise à jour est disponible et vous demande si vous souhaitez la mettre à jour. Sélectionnez OUI. Si vous l'exécutez dans un terminal/konsole avec les permissions root, le script sera mis à jour. Lancez ensuite le script une seconde fois. Une fois terminé, il vous transmettra une URL. Jetez un coup d'oeil au contenu de l'URL, car il vous transmet des informations utiles. Gardez également une trace de l'URL fournie par le script car elle peut être utile pour passer à d'autres personnes qui essaient de vous aider (sur l'un des forums, ou sur un canal IRC). Passez ensuite à l'étape suivante de ce guide.
Alternativement, pour les utilisateurs avec alsa 1.0.16 ou une version plus ancienne, vous devez télécharger et exécuter le script. Pour ce faire, copiez et collez la ligne ci-dessous dans un gnome-terminal/konsole) et exécutez :
wget http://www.alsa-project.org/alsa-info.sh
puis lancez le script alsa-info.sh (copiez et collez ceci dans un gnome-terminal/konsole) :
bash alsa-info.sh
Gardez une trace de l'URL fournie par le script car elle peut être utile pour passer à d'autres personnes qui essaient de vous aider (sur l'un des forums, ou sur un canal IRC).
Maintenant, regardez bien ces pages de script, et essayez de déterminer quel codec audio votre matériel de son PC possède. Par exemple, il peut s'agir d'un ALC650, ou d'un ALC268, AD1986A, STAC9220, etc...
Méthode alternative pour exécuter le script
Pour ceux qui trouvent les instructions ci-dessus sur l'exécution des deux scripts de diagnostic trop difficiles, alors en tant que simple utilisateur, essayez de copier et coller chacune des deux lignes ci-dessous (une à la fois) dans un terminal xterm/konsole pour télécharger et exécuter les scripts. Copiez la ligne COMPLETE. La seconde (tsalsa) vous demandera le mot de passe root.
alsa-info.sh
wget -O alsa-info.sh http://www.alsa-project.org/alsa-info.sh && bash alsa-info.sh
Rechercher sur le site alsa des informations sur les codecs
Maintenant, armé de ces informations de codec, allez sur le site web d'alsa, et faites une recherche pour voir s'il y a des informations pertinentes sur ce codec :
http://www.alsa-project.org/main/index.php/Main_Page
Il y a une boîte de recherche sur le côté gauche de cette page (en partie en bas). Disons que votre codec audio était ALC268. Alors une recherche pour ça pourrait indiquer :
http://www.alsa-project.org/main/index.php/Special:Search?search=ALC268&go=Go
Si, par exemple, votre openSUSE a la version alsa-1.0.14, on peut voir qu'il y a eu beaucoup de mises à jour de l'ALC268 entre alsa-1.0.14 et alsa-1.0.15, qui est pertinente dans cet exemple. Il peut y avoir d'autres mises à jour dans alsa-1.0.16.
Vous pouvez le vérifier plus en détail dans la release note détaillée pour alsa-1.0.15 ici :
http://www.alsa-project.org/main/index.php/Changes_v1.0.14_v1.0.15_detail
ou en consultant la note de publication alsa-1.0.16 :
http://www.alsa-project.org/main/index.php/Changes_v1.0.15_v1.0.16_detail
Faire une recherche sur cette page indiquera de nombreux changements avec cette nouvelle version alsa pour ALC268. Dans ce cas, il faut envisager une mise à jour vers alsa-1.0.16 (voir ci-dessous pour des conseils sur la mise à jour vers alsa-1.0.16).
Si après avoir fait ces recherches, il apparaît que alsa-1.0.14 (ou n'importe quelle version d'alsa de votre openSUSE) semble adéquate, alors il est possible que vous deviez faire une édition manuelle personnalisée dans votre fichier /etc/modprobe.d/sound et ajouter une spécification de modèle (et passer à l'étape 5 ci-dessous). Mais si la mise à jour vers alsa-1.0.14 semble utile, passez à l'étape 4 ci-dessous :
ETAPE-4 : Mise à jour d'alsa dans openSUSE
Si la mise à jour d'alsa est jugée nécessaire, cela peut se faire soit par rpm, soit par un fichier archive. Comme toujours, l'utilisateur non expert d'openSUSE devrait d'abord essayer de mettre à jour via un rpm, avant d'essayer via un fichier archive (TARBALL).
Mise à jour d'alsa via rpm
Pour openSUSE, le développeur openSUSE alsa packager / alsa developer empaquette également la dernière version d'alsa sous forme de rpms openSUSE, afin d'aider les utilisateurs dont le son ne fonctionne pas correctement, en fournissant des pilotes audio de la plus récente version.
Les applications rpm qui sont généralement mises à jour incluent alsa, alsa-utils, alsa-tools, et libasound2 alsa-firmware. Notez que le firmware alsa-firmware se trouve dans la section "noarch" de l'URL rpm. De plus, il y a des modules du noyau du pilote ALSA à mettre à jour.
Il est souvent plus facile d'ajouter l'URL du référentiel noté dans la section suivante à son gestionnaire de paquets, et d'installer les applications rpm via son gestionnaire de paquets.
Commandes RPM pour mettre à jour alsa pour openSUSE-11.0 à 11.2 (divers noyaux)
Des exemples spécifiques pour différentes versions d'openSUSE, et pour différentes versions du noyau, avec des commandes zypper spécifiques pour openSUSE-11.0 à 11.2 sont fournis ici : SDB:Alsa-update
si après le redémarrage, les rpms installés après avoir suivi cette URL n'aident pas, alors il y a aussi des snapshots alsa quotidiens packagés et disponibles ici : SDB : Alsa-update-snapshot
Veuillez consulter l'URL ci-dessus. Il fournit un lien avec des exemples de commandes exactes pour différentes versions d'openSUSE et différentes versions du noyau. Notez également que vous pouvez vérifier votre noyau (avant d'exécuter les commandes zypper ci-dessus documentées dans le lien/URL fourni) en tapant :
Pour déterminer votre version d'openSuSE et votre version d'architecture système, vous pouvez taper :
Notez également que pour que ces alsa rpms "de pointe" puissent être installés sans problèmes de dépendance, vous devez vous assurer d'avoir mis à jour le dernier noyau pour votre openSUSE fourni par, et recommandé par Novell/SuSE-GmbH. Si vous avez choisi de ne pas mettre à jour le dernier noyau, vous devrez alors modifier les commandes zypper, en faisant référence à un répertoire de référentiel différent, qui supporte l'ancien noyau openSUSE-10.3 (original) de votre PC.
Pour tous les utilisateurs d'openSUSE, après avoir installé cette dernière version d'alsa, son redémarrage le plus simple (pour recharger ce pilote alsa mis à jour) est de recommencer toutes les étapes précédentes de cette page, pour voir si vous pouvez faire fonctionner votre son sous cette nouvelle alsa. Notez qu'il se peut que l'un d'eux n'ait toujours pas de son, et vous devrez peut-être éditer votre fichier /etc/modprobe.d/sound (voir Étape-5 ci-dessous), et ajouter une spécification de modèle. Aussi, si la mise à jour d'alsa ci-dessus restaure votre son, alors faites attention à ne pas appliquer d'autres mises à jour d'alsa. Les rpms d'alsa sur ce site web sont très " de pointe ", ils sont construits régulièrement, et ils pourraient avoir récemment introduit des bugs qui n'ont pas encore été corrigés. Par conséquent, une fois que vous avez fait fonctionner votre son, vous devez supprimer ce référentiel multimédia "de pointe" (tout en conservant les rpms installés).
Mise à jour d'alsa via une archive
On peut aussi compiler alsa pour son PC en allant à l'URL ci-dessous et en téléchargeant les archives tarballs alsa alsa-driver, alsa-firmware, alsa-lib, alsa-utils, et alsa-tools : http://www.alsa-project.org/main/index.php/Download Attention, .... ce genre de mise à jour via une compilation personnalisée d'alsa depuis une archive tarball n'est généralement pas pour les nouveaux utilisateurs. Essayez plutôt de suivre la méthode de mise à jour de rpm via la commande zypper, décrite ci-dessus.
Les fichiers readme.txt et install.txt fournissent des instructions pour compiler à partir de tarball. De plus, des instructions d'installation personnalisées sont également disponibles sur le site web d'alsa. Dans notre cas, pour l'ALC268, le module de son du noyau est le : snd-hda-intel (que nous avons appris ci-dessus en tapant : cat /proc/asound/modules
). Rechercher snd-hda-intel sur le site alsa donne cette page qui fournit des instructions personnalisées pour compiler alsa :
http://www.alsa-project.org/main/index.php/Matrix:Module-hda-intel
Il en va de même pour la plupart des modules de son. Une fois alsa compilé et installé, redémarrez votre PC pour charger le module son, puis reprenez toutes les étapes précédentes de cette page, pour voir si vous pouvez faire fonctionner votre son sous la nouvelle alsa. Notez qu'il se peut qu'on n'ait toujours pas de son, et qu'on veuille modifier son fichier /etc/modprobe.d/sound
selon les recommandations de la page alsa, ou qu'on veuille essayer de modifier son fichier /etc/modprobe.d/sound
(en ajoutant un modèle) comme indiqué ci-dessous.
Étape-5: Ajouter le “modèle” de la carte son au fichier /etc/modprobe.d/<file>
Pour spécifier le modèle de votre carte son dans le fichier /etc/modprobe.d/sound
(/etc/modprobe.d/50-sound.conf
sur openSUSE-11.2,11.3), vous devez d'abord déterminer quelles spécifications du modèle appliquer. Il y a un fichier ALSA-Configuration.txt sur votre PC que vous pouvez examiner (dans un répertoire du type suivant, selon la version de votre noyau) :
/usr/src/linux-2.6.22.13-0.3/Documentation/sound/alsa/ALSA-Configuration.txt
Il y a aussi un fichier ALSA-Configuration.txt à jour ici : http://hg.alsa-project.org/alsa-kernel/raw-file/5082de4abb26/Documentation/ALSA-Configuration.txt
Depuis la version 1.0.19 d'alsa, les options HD-Audio-Models sont listées dans le fichier HD-Audio-Models.txt.
Il y a un excellent exemple de la façon de faire cette configuration manuelle ici : SDB:Intel-HDA_problèmes_sonore_HDA
Dans notre exemple de l'ALC268, vous verrez :
ALC268 3stack 3-stack model toshiba Toshiba A205 acer Acer laptops dell Dell OEM laptops (Vostro 1200) zepto Zepto laptops test for testing/debugging purpose, almost all controls can adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y auto auto-config reading BIOS (default)
Allez maintenant dans votre fichier /etc/modprobe.d/sound
(/etc/modprobe.d/50-sound.conf
sur openSUSE-11.2) et cherchez une ligne qui ressemble à ceci :
"options snd-hda-intel enable=1 index=0
"
et ajoutez une spécification de modèle à la fin de cette ligne. Si vous avez essayé pour la dernière fois de configurer votre son avec "alsaconf" (sur openSUSE-11.1 ou antérieur), il est possible qu'il n'y ait aucune ligne de ce type, auquel cas vous devrez ajouter une ligne similaire à l'exemple ci-dessous. Pour le codec ALC268, si vous avez clairement un ordinateur portable "acer" ou "toshiba", alors le choix de ce que vous pouvez essayer en premier est clair. Mais c'est toujours possible que l'un d'entre eux fonctionne avec votre audio, même si votre matériel n'est pas celui d'un "acer" ou d'un "toshiba" et vous devriez toujours essayer ces modèles de façon itérative.
Ainsi par exemple (pour utiliser l'option de modèle toshiba) ajoutez la ligne au fichier : options snd-hda-intel model=toshiba
Sauvegardez le fichier, et redémarrez votre pilote alsa, en tapant un konsole/xterm, avec les droits root :
Testez ensuite votre son à l'aide du test sonore fourni au début de cette page Web. N'oubliez pas de vérifier que votre mixer n'est pas muet ou bloque le son.
Si cela ne fonctionne pas, éditez à nouveau votre fichier /etc/modprobe.d/sound
(/etc/modprobe.d/50-sound.conf
sur openSUSE-11.2), en essayant les différentes options (par exemple "acer" et "3stack") tout en vous assurant de recommencer votre alsa à chaque modification.
Dans certains des exemples de codecs matériels les plus complexes, par exemple l'ALC880 :
ALC880 3stack 3-jack in back and a headphone out 3stack-digout 3-jack in back, a HP out and a SPDIF out 5stack 5-jack in back, 2-jack in front 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out 6stack 6-jack in back, 2-jack in front 6stack-digout 6-jack with a SPDIF out w810 3-jack z71v 3-jack (HP shared SPDIF) asus 3-jack (ASUS Mobo) asus-w1v ASUS W1V asus-dig ASUS with SPDIF out asus-dig2 ASUS with SPDIF out (using GPIO2) uniwill 3-jack fujitsu Fujitsu Laptops (Pi1536) F1734 2-jack lg LG laptop (m1 express dual) lg-lw LG LW20/LW25 laptop tcl TCL S700 clevo Clevo laptops (m520G, m665n) test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y auto auto-config reading BIOS (default)
Vous devez déterminer le nombre de prises de votre matériel (jetez un coup d'oeil) pour voir s'il est adapté pour essayer 3-stack, ou 5stack, ou 6-stack, ou une interface de sortie S/PDIF ... alors vous pourrez peut-être réduire les options que vous essayez, pour trouver le réglage optimal au plus vite..
Et puis essayez chacune des options de modèle en ajoutant "model= ...... " au fichier /etc/modprobe.d/sound
(/etc/modprobe.d/50-sound.conf
sur openSUSE-11.2). N'oubliez pas de redémarrer alsa après chaque tentative.
Attention ! Ne mettez pas de fichiers de sauvegarde de 'son' (ou de sauvegardes de quoi que ce soit d'autre) dans /etc/modprobe.d/ car cela serait également lu et chargé ! Mettez vos sauvegardes ailleurs.
ÉTAPE-6 : Comment résoudre un problème de permissions
Dans certains cas, l'utilisateur root aura du son, mais un utilisateur régulier n'en aura pas. Typiquement, cela est dû à un problème de permissions rencontré par l'utilisateur régulier. HAL/ConsoleKit/PolicyKit accordera automatiquement la permission à l'utilisateur en ajoutant les entrées ACL appropriées sur /dev/snd/* (et autres fichiers de périphériques) pour les connexions locales (vous ne voulez pas que les utilisateurs se connectent à distance pour jouer du son sur votre machine, non ?) - console, gdm, kdm. A une exception près : xdm n'est plus supporté par PolicyKit depuis Xorg 7.4.
Etant donné que HAL le fera dans la plupart des cas, il ne devrait pas être nécessaire de vous ajouter au groupe "audio" dans des circonstances normales. Si l'ajout au groupe est jugé nécessaire, il peut se faire avec l'un ou l'autre :
- YAST » Sécrité et utilisateurs » Gestion des groupes et utilisateurs » “sélectionnez votre utilisateur” » Modifier » Détails » Groupes » cochez “audio” puis cliquez sur “OK”
ou exécutez en tant que root
si vous utilisez openSUSE 12.3 ou une version plus récente. Sinon, sur openSUSE <= 12.2, exécutez
La nouvelle appartenance à un groupe sera valable pour les processus démarrés à partir de la prochaine connexion.
ÉTAPE 7 : Problèmes de PulseAudio
Depuis openSUSE-11.0, PulseAudio a été introduit dans openSUSE. Cette introduction initiale de PulseAudio a créé quelques problèmes avec les utilisateurs de Gnome et de KDE4 (les utilisateurs de KDE-3.5.9 n'ont pas été affectés). Pour plus d'informations sur la façon de résoudre certains problèmes Pulse Audio, reportez-vous à la section
- http://www.pulseaudio.org/wiki/FAQ et
- http://en.opensuse.org/SDB:Pulseaudio et
- http://pulseaudio.org/wiki/BrokenSoundDrivers
Sur openSUSE-11.1 et 11.2, PulseAudio fonctionne beaucoup mieux.
Correction possible d'un son saccadé/sautant
Le serveur de son PulseAudio a été conçu pour utiliser une programmation audio basée sur une minuterie au lieu de l'approche traditionnelle basée sur les interruptions. C'est l'approche adoptée par d'autres systèmes tels que Apples CoreAudio et le sous-système audio Windows Vista, qui présente un certain nombre d'avantages, notamment en termes de réduction de la consommation d'énergie, de réduction des pertes et pour une adaptation souple du temps d'attente aux besoins de l'application. Toutefois, la planification basée sur la minuterie peut entraîner des problèmes chez certains pilotes Alsa. Pour désactiver la planification basée sur la minuterie, remplacez la ligne load-module module-hal-detect dans /etc/pulse/default.pa par load-module module-hal-detect tsched=0
Alternativement, dans les cas où udvev est utilisé au lieu de hal, essayez de remplacer la ligne load-module module-udev-detect dans /etc/pulse/default.pa par (ou en ajoutant si la ligne n'est pas présente) load-module module-udev-detect tsched=0
Dans d'autres cas, le son haché avec pulsaudio peut résulter d'un mauvais réglage de la fréquence d'échantillonnage dans /etc/pulse/daemon.conf . Essayez de changer la ligne default-sample-rate = 44100 dans /etc/pulse/daemon.conf par default-sample-rate = 48000 et redémarrez le serveur PulseAudio.
ÉTAPE-8 : Problèmes audio du phonon KDE4
Phonon a été introduit sur openSUSE-11.0 avec KDE4, et il peut parfois causer des problèmes. Pour plus d'informations sur la gestion des problèmes audio liés à Phonon, reportez-vous à la page de dépannage audio de kde.org phonon : http://phonon.kde.org/cms/1032
ÉTAPE-9 : Déterminer l'ordre des dispositifs sonores
Avec l'avènement des cartes vidéo avec sorties HDMI, beaucoup d'ordinateurs ont maintenant plusieurs périphériques de son. Si le mauvais périphérique audio a été configuré en premier, il se peut que le son soit envoyé au mauvais périphérique. Bien que Phonon vous permette de déterminer quel périphérique audio doit être utilisé "en premier" dans KDE4, toutes les applications n'obéissent pas à cette préférence, et les utilisateurs Gnome n'ont de toute façon pas l'avantage de Phonon. Si c'est le cas, la chose la plus simple à faire est de changer manuellement l'ordre des périphériques audio dans YAST. Les instructions suivantes sont basées sur openSUSE 11.2, mais sont probablement les mêmes pour toutes les versions antérieures ;
Tout d'abord, démarrez YAST et ouvrez le module " Son " dans la section " Matériel ". S'il y a plusieurs périphériques audio, ils seront listés ici. La colonne "Index" commence à 0 pour le premier périphérique audio, puis à 1 pour le second, 2 pour le troisième, etc. Dans certains cas, le mauvais dispositif peut être réglé à l'index 0, ce qui causerait des problèmes sonores dans de nombreuses applications.
Le but est d'avoir votre périphérique audio préféré comme index 0 pour s'assurer que toutes les applications l'utilisent par défaut. Vous pouvez le faire en sélectionnant chaque périphérique sonore, puis en cliquant sur le bouton "Supprimer" en bas de la fenêtre pour supprimer la configuration de chaque périphérique. Cela change l'index de ce périphérique en "Non configuré" et le déplace vers le bas de la liste.
Une fois qu'ils ont tous été effacés, sélectionnez votre appareil préféré (celui d'où vous voulez entendre le son) et cliquez sur le bouton "Modifier" pour le configurer. S'il a déjà été configuré automatiquement lors de l'installation d'openSUSE, le choix de " Configuration automatique rapide " dans la fenêtre suivante devrait fonctionner correctement. Une fois configuré, ce périphérique sera à l'index 0 et en haut de la liste. Vous pouvez choisir de ne pas configurer d'autres appareils ou de les configurer au cas où vous auriez l'intention de les utiliser. Dans mon cas, je n'ai jamais l'intention d'utiliser la sortie audio HDMI de ma carte vidéo, donc je ne l'ai pas configurée.
Si vous n'êtes pas sûr de savoir quel appareil est celui que vous voulez en premier dans la liste, essayez chacun à l'index 0 jusqu'à ce qu'il fonctionne, un à la fois. Vous devrez peut-être vous déconnecter et vous reconnecter à votre compte pour vous assurer que les modifications ont été appliquées avec succès après chaque tentative.
chipset Intel HDA
Lorsque vous utilisez l'audio intégré de votre processeur Intel Haswell, l'ordre audio par défaut est d'abord HDMI, puis "PCH" (analogique). Changer l'ordre via la configuration du son d'OpenSuse 13.2 du Centre de Contrôle Yast ne fonctionnera probablement pas car Yast essaiera de définir l'ordre en utilisant :
options snd slots=snd-hda-intel,snd-hda-intel
Pour résoudre ce problème, ouvrez /etc/modprobe.d/50-sound.conf et changez le en:
alias snd-card-1 snd-hda-intel
alias snd-card-0 snd-hda-intel
options snd-hda-intel id=PCH index=0
options snd-hda-intel id=HDMI index=1
Pour le "id" à utiliser, voir la sortie de "aplay -l".
Configuration du microphone
Une attention particulière doit être portée aux réglages de la table de mixage lorsque l'on essaie d'utiliser le microphone. Dans KDE typiquement "kmix" est le mixer, et dans gnome typiquement "alsamixer" est le mixer. Pour plus d'informations sur la façon de tester son microphone, consultez la page Microphone.
Configuration d'un casque Bluetooth
Pour les utilisateurs d'openSUSE-11.1, voici un guide pour configurer votre oreillette Bluetooth avec openSUSE-11.1: SDB:Bluetooth headphones
Configuration du casque d'écoute USB
Les utilisateurs de KDE3 peuvent suivre ce qui suit pour obtenir des conseils sur la configuration de leur casque USB : SDB:USB_headphones Les étapes de KDE4 peuvent différer.
Configuration des touches multimédia d'un ordinateur portable
Une approche pour fournir les fonctionnalités de base des touches multimédia d'un ordinateur portable (telles que l'augmentation ou la diminution du volume) peut être implémentée par l'application Keytouch (fournie par Packman Packagers pour openSUSE) en ajoutant les appels à l'application alsa amixer. Il y a un guide avec un exemple pour faire une telle configuration ici : http://akoskm.blogspot.com/2009/01/laptop-extra-keys-howto.html et un wiki en développement : SDB:Keytouch
Déterminer quelle application utilise un dispositif sonore
Parfois, quand on a un son de base qui fonctionne, mais qu'il semble s'arrêter au milieu d'une session (à restaurer après un redémarrage), c'est peut-être parce qu'une application a saisi votre périphérique audio, et que l'application ne partage ni se désactive du périphérique audio. Pour déterminer l'application qui utilise son périphérique audio, copiez et collez ce qui suit dans un terminal ou une console :
Si l'on exécute la ligne ci-dessus à différents moments, lorsque le son fonctionne et ne fonctionne pas, on peut mieux comprendre ce que signifie la sortie, et être mieux en mesure de " pointer du doigt " l'application fautive qui a saisi le périphérique audio.
Documentation du pilote ALSA
On peut se renseigner sur les aspects techniques d'alsa en installant le rpm "alsa-docs" et en le copiant dans son navigateur web : file:///usr/share/doc/packages/alsa-docs/index.html
Un peu de magie
Pour tester votre son en ligne de commandes :
Pour tester le microphone :
et
pour vérifier l'enregistrement.
Liens externes
- Page principale du projet ALSA : http://www.alsa-project.org/main/index.php/Main_Page
- ALSA-Configuration.txt http://hg.alsa-project.org/alsa-kernel/raw-file/5082de4abb26/Documentation/ALSA-Configuration.txt
- ALSA opensource wiki: http://alsa.opensrc.org/index.php/Main_Page
- Linux Journal: Troubleshooting Linux Audio Part-1: http://www.linuxjournal.com/node/1000244
- Linux Journal: Troubleshooting Linux Audio Part-2: http://www.linuxjournal.com/node/1000254
- Linux Journal: Troubleshooting Linux Audio Part-3a: http://www.linuxjournal.com/node/1000262
- Linux Journal: Troubleshooting Linux Audio Part-3b: http://www.linuxjournal.com/node/1000295
- AlsaMixers reference: http://alsa.opensrc.org/index.php/AlsaMixers