[pulseaudio] Impossible de lancer pulseaudio !

[FredBezies]

Salut

NB : j'ai aussi poser la question sur le forum anglophone, histoire de multiplier les réponses

Voila, suivant la page de wiki : http://wiki.archlinux.org/index.php/PulseAudio , je voudrais installer pulseaudio, qui sera le démon qui a de forte chance de remplacer ESD pour Gnome dès la version 2.22.0.

Hors, c'est la mouise

Code : Tout sélectionner

[root@fredo-arch fred]# /etc/rc.d/pulseaudio start
:: Starting PulseAudio                                                   [BUSY]
E: main.c: daemon startup failed.

En lançant directement le fichier pulseaudio, c'est déjà plus bavard :

Code : Tout sélectionner

[root@fredo-arch rc.d]# pulseaudio start
W: main.c: This program is not intended to be run as root (unless --system is specified).
W: alsa-util.c: Device (null) doesn't support 44100 Hz, changed to 48000 Hz.
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL front:0
W: alsa-util.c: Device (null) doesn't support 44100 Hz, changed to 48000 Hz.
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL front:0
E: module.c: Failed to open module "module-esound-protocol-unix": libsocket-util.so: Cannot open shared file: No such file or directory
E: main.c: Module load failed.
E: main.c: failed to initialize daemon.

Et le fichier semble vraiment manquer à l'appel :

Code : Tout sélectionner

[fred@fredo-arch rc.d]$ yaourt -Ql pulseaudio | grep socket
pulseaudio /usr/lib/pulse-0.9/modules/libsocket-client.so
pulseaudio /usr/lib/pulse-0.9/modules/libsocket-server.so

Donc, une idée ?! Mis à part recompiler le paquet pour intégrer le fichier manquant ?!

[tuxce]

salut, j'ai pas vraiment de solution, mais juste une remarque sur

En lançant directement le fichier pulseaudio, c'est déjà plus bavard :

Code : Tout sélectionner

[root@fredo-arch rc.d]# pulseaudio start

en fait, la tu lances directement le daemon (dans le $PATH) et non le script (qu'il faut lancer avec "./")
et pour avoir plus de sortie:

Code : Tout sélectionner

pulseaudio --system -vv

sinon, tu peux commenter le chargement du module depuis: /etc/pulse/default.pa

si je me rappelle quelque lectures, c'est pour garder la compatibilité avec esd, je sais pas si elle est nécessaire...

[FredBezies]

salut, j'ai pas vraiment de solution, mais juste une remarque sur

En lançant directement le fichier pulseaudio, c'est déjà plus bavard :

Code : Tout sélectionner

[root@fredo-arch rc.d]# pulseaudio start

en fait, la tu lances directement le daemon (dans le $PATH) et non le script (qu'il faut lancer avec "./")
et pour avoir plus de sortie:

Code : Tout sélectionner

pulseaudio --system -vv

sinon, tu peux commenter le chargement du module depuis: /etc/pulse/default.pa

si je me rappelle quelque lectures, c'est pour garder la compatibilité avec esd, je sais pas si elle est nécessaire...

Pour info, j'ai viré actuellement pulseaudio, esd se charge, mais j'ai plus de son.

/me en a plein le

[warnaud]

Je connais pas pulseaudio j'utilise que alsa :p
Mais le mieux est souvent l'ennemi du bien surtout quand c'est pas en standard

Pas de panique je suis sûr que tu vas y arriver

[FredBezies]

J'ai fini par trouver les réglages pour lancer le daemon.

Le seul point qui manque : l'enrobage du démon ESD :

Code : Tout sélectionner

$ esd
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL front:0
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL front:0

Une idée ?

[FredBezies]

J'ai fini par laisser tomber, apparamment l'alpha 4 de la Ubuntu Hardy Heron semble connaître ce genre de désagrement.

Sans oublier que le paquet pulseaudio pour x86_64 est bien pourri

/me en a sa claque des paquets x86_64 pourri

[warnaud]

C'est pas forcément que la faute des pkgs x86_64, certe ils devraient être testés, mais après sur ce genre de programmes avec des dépendances en cascades, en plus en 64bits (qui a du mal a devenir un standard).

Perso j'ai une install de arch spécialement pour faire des tests ... en gros un / séparé de ma arch "stable" comme ça, je stresse pas si y'a une mise à jour pourrie ou un truc louche a tester

[FredBezies]

C'est pas forcément que la faute des pkgs x86_64, certe ils devraient être testés, mais après sur ce genre de programmes avec des dépendances en cascades, en plus en 64bits (qui a du mal a devenir un standard).

Surtout 95% des CPUs intel et AMD sont des 64 bits désormais.

Perso j'ai une install de arch spécialement pour faire des tests ... en gros un / séparé de ma arch "stable" comme ça, je stresse pas si y'a une mise à jour pourrie ou un truc louche a tester

je fais de même avec mon arch64 via une machine vmware.

Quoique je suis content, j'ai réussi à faire fonctionner les gnome-system-tools avec perl 5.10

Une simple recompilation des paquets perlxml, perl-xml-simple et de system-tools-backends a réglé le problème