Quels paramètres utilisateur contrôlent l'accès audio?

Avec un LTS 10.04 régulièrement mis à jour, nous avons un problème étrange avec l'accès à l'audio avec pulseaudio 0.9.22. Le périphérique audio estATI Technologies Inc SBx00 Azalia (Intel HDA)

• Connectez-vous à user1 après le redémarrage: son OK
• Connectez-vous à user2 après le redémarrage: son OK
• Login user1 puis user2 : son OK: les deux ont du son

mais

• Login user2 puis user1 : seul user2 a du son
• Connectez-vous à user2 après le démarrage, déconnectez-vous à user2 , puis connectez-vous à user1 : aucun son

et

• Connectez - vous user3 alors user1 : tout est bon!

Dans les deux derniers cas, user1 obtient des erreurs répétées dans syslog:

protocol-native.c: Denied access to client with invalid authorization data

Ces erreurs disparaissent seulement après PulseAudio est démarré à partir user1 manuellement dans un terminal. Ensuite, l'accès audio est bien pour les deux. Il y a une erreur module-alsa-card.c: Failed to find a working profilemais la sortie du son est toujours correcte.

Nous ne sommes pas tous les deux membres du groupe audio. La suppression ~/.pulsedes deux comptes n'a aucun effet sur ce comportement.

Le problème a commencé dans 9.10 Karmic et a continué d'être présent même après une mise à niveau vers 10.04 Lucid LTS. Cela indique que certains paramètres erronés ont survécu aux mises à niveau.

La dépendance de l'ordre de démarrage des utilisateurs indique que d'autres paramètres spécifiques à l'utilisateur peuvent être impliqués, mais nous ne savons pas par où commencer la recherche. D'après les tests avec 3 utilisateurs, il semble que seuls les paramètres de l'utilisateur2 soient rompus .

Le chargement des modules pulseaudio module-esound-protocol-unixet module-native-protocol-unixavec l'option auth-anonymous=1dans default.pa et system.pa n'a pas changé ce comportement. Il n'a pas non plus aidé à supprimer les cookies pulseaudio ~/.esd_authet ~/.pulse-cookiedes deux utilisateurs.

Voici notre default.pa et notre system.pa .

Les suggestions 1) à 8) de la réponse ci - dessous n'ont pas changé (l'exécution de pulseaudio en mode système n'était pas possible) mais débrancher le haut-parleur externe, redémarrer, rebrancher le haut-parleur et redémarrer à nouveau à partir de l'utilisateur1 a fait l'affaire.

On ne sait toujours pas où ces informations sur le matériel ont été (erronément) stockées et pourquoi elles n'ont affecté qu'un seul compte d'utilisateur.

1) Voulez-vous essayer ceci avec l'utilisateur 1:

sudo gpasswd -un accès par impulsions utilisateur1
sudo gpasswd -a user1 pulse-rt
sudo gpasswd -a impulsion audio

2) Avez-vous essayé cela?

"modifiez /usr/local/etc/pulse/system.pa et ajoutez:

load-module module-native-protocol-unix auth-anonymous=1

Référence: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-January/002942.html

3) Essayez d'exécuter pulseaudio en mode système

Référence: https://bugzilla.redhat.com/attachment.cgi?id=262541

4) Assurez-vous que user2 n'exécute pas pulseaudio en tant que root

5) Supprimez les applications de l'utilisateur 2 qui peuvent ne pas libérer l'audio (par exemple la timidité)

6) Passez au travers ~/.asoundrcet /etc/asound.confsi présent

7) Vérifiez si " la bibliothèque evil libflashsupport " est installée. Pour désinstaller:

 sudo aptitude purge libflashsupport flashplugin-nonfree-extrasound  

8) Démarrez le système démon pulseaudio à l'échelle:

gksu gedit /etc/default/pulseaudio  

Et changez "PULSEAUDIO_SYSTEM_START = 0" pour "PULSEAUDIO_SYSTEM_START = 1"

9) Essayez de débrancher le matériel audio comme les haut-parleurs externes et redémarrez.