# pulseaudio via reseau

## Chr0nos

Bonjours,

je tente de actuelement d'utiliser mon pc sous gentoo pour lire les sons de mes autres pc (car je n'ai qu'un seul kit d'enceintes) mais voila: configurer pulseaudio en mode serveur est hyper tendu et apparement "mal" (c'est pulseaudio qui le dis dans les logs)

donc dans l'idée je voudrais que le pc sous gentoo joue le role de "serveur de son" sur mon reseau local, et que tout arrive sur ce pc la

j'ai donc trifouillé les fichiers de config de la façon suivante:

/etc/systemd/system/pulseaudio.service

 *Quote:*   

> #systemd service spec for pulseaudio running in system mode -- not recommended though!
> 
> # on arch, put it under /etc/systemd/system/pulseaudio.service
> 
> # start with: systemctl start pulseaudio.service
> ...

 

client.conf

 *Quote:*   

> stark pulse # cat client.conf 
> 
> # This file is part of PulseAudio.
> 
> #
> ...

 

system.pa

 *Quote:*   

> #!/usr/bin/pulseaudio -nF
> 
> #
> 
> # This file is part of PulseAudio.
> ...

 

default.pa

 *Quote:*   

> #!/usr/bin/pulseaudio -nF
> 
> #
> 
> # This file is part of PulseAudio.
> ...

 

daemon.conf

 *Quote:*   

> # This file is part of PulseAudio.
> 
> #
> 
> # PulseAudio is free software; you can redistribute it and/or modify
> ...

 

et la je n'ai plus de son du tout sur ma machine (je n'en suis donc pas a permetre des connection "exterieures" )

j'ai installé le paquet papref mais rien de "mieux" ne semble se produire

sinon je ne pourais pas me passer du mode serveur et juste "écouter" les connections entrantes et que pulseaudio se lance de lui meme (comme avant donc) ?

désolé pour toutes ces questions un peu tordues mais si on "peut" le faire, pourquoi ne pas éssayer ? :p

d'avance merci   :Rolling Eyes: 

----------

## DuF

Bonjour,

Je ne suis pas sûr d'avoir compris ton besoin. Ce que tu souhaites c'est que ton PC gentoo soit le seul qui s'occupe du son et qu'il reçoive le son de tes autres PCs ? Dans ce cas c'est sur les autres PCs qu'il faut configurer les démons audios pour sortir sur le réseau ?

Parce que j'ai plutôt l'impression que tu as configuré pulseaudio en mode serveur et que lui diffuse sur le réseau.

Pour connaitre l'état de ton pulseaudio, peux-tu donner le résultat des commandes pactl stat et pactl info ?

Sinon est-ce que le besoin se limite à de la lecture musicale ? Si oui dans ce cas mpd me parait plus approprié.

----------

## Chr0nos

Bonjour

tu à parfaitement compris ce que je cherche à faire, le pc sous gentoo doit recevoir tous les sons des autres ordis (du moin etre pret à le faire puisque le premier second ordi est sous windows7 donc ca n'a rien à faire ici xD)

et non ce besoin s'étends à absolument tout le son, mon pc windows me sert uniquement à jouer et à modeliser sous solidworks

j'ai repassé pulseaudio comme avant, voici le resulta des commandes que tu demandais:

 *Quote:*   

> stark pulse # pactl stat
> 
> No protocol specified
> 
> xcb_connection_has_error() returned true
> ...

 

le son marche localement la

mais sur l'autre machine sous windows7 je ne parviens pas a faire fonctioner le son

j'arrive bien à voir les prériferiques du serveur sous gentoo, mais c'est tout

voila ce que j'ai:

http://img849.imageshack.us/img849/4841/6aag.jpg

et dans la liste des sinks:

http://img196.imageshack.us/img196/9632/6asx.jpg

le system.pa

 *Quote:*   

> #
> 
> # This file is part of PulseAudio.
> 
> #
> ...

 

le client.pa

 *Quote:*   

> # This file is part of PulseAudio.
> 
> #
> 
> # PulseAudio is free software; you can redistribute it and/or modify
> ...

 

mon server.bat

 *Quote:*   

> c:\pulseaudio\bin\pulseaudio.exe -p c:\pulseaudio\lib\pulse\modules -nF etc\pulse\default.pa

 

je n'arrive pas a faire en sorte que pulseaudio agisse comme une sortie son indépendente (donc que je pourais choisir parmis mes sorties)

----------

## DuF

Sur ta machine windows, il liste une sortie analogique et une entrée analogique pour une carte son USB (un casque gamer a priori avec carte son inclus) => est-ce bien cela que tu souhaites en périphérique par défaut ?

Est-ce que la sortie analogique qu'il indique (de ce casque audio) correspond à ce que tu as sous gentoo ?

Sur le windows peux-tu faire la commande "pactl info" afin de savoir quelle est la source par défaut et le sink par défaut (j'ai supposé que ce que tu as mis dans ton précédent mail pour le pact stat correspondait à ta gentoo) ?

[EDIT] j'ai oublié de demander, as-tu sur la gentoo utiliser à un moment ou un autre l'outil "paprefs" notamment pour activer "Multicast/RTP Receiver." ? J'ai eu des soucis en configurant d'un côté par l'outil et de l'autre par fichier.

----------

## Chr0nos

alors oui j'ai utilisé paprefs sur la gentoo pour configurer le receiver 

sur la machine windows:

 *Quote:*   

> 
> 
> cd c:\pulseaudio\bin\
> 
> pactl.exe info
> ...

 

les arguments qu'il accepte:

stat / list / exit / unload-sample / play-sample / remove-sample / move-sink-input / move-source-output / load-module / unload-module / suspend-sink / suspend-source / set-card-profile / set-sink-port / set-source-port  / set-sink-volume / set-source-volume / set-sink-input-volume / set-sink-mute / set-source-mute / set-sink-input-mute / subscribe

et sinon oui le casque audio est la sortie que je veu utiliser pour le moment (j'imagine que cela basculera sur les enceintes quand il sera débranché)

EDIT:

du coté du pc gentoo j'ai ca dans les logs en mode pulseaudio-daemon

 *Quote:*   

> Feb 10 14:08:19 localhost pulseaudio[25307]: [pulseaudio] source.c: Created source 4 "alsa_input.usb-Ma_TRITTON_AX-180_Headset-00-Headset.analog-mono" with sample spec s16le 1ch 44100Hz and channel map mono
> 
> Feb 10 14:08:19 localhost pulseaudio[25307]: [pulseaudio] source.c:     alsa.resolution_bits = "16"
> 
> Feb 10 14:08:19 localhost pulseaudio[25307]: [pulseaudio] source.c:     device.api = "alsa"
> ...

 

ca peut venir de la ?

----------

## DuF

Oui clairement que ça peut venir de là, mais en gros si je suis bien tes logs, ton serveur pulseaudio sur la gentoo n'est pas opérationnel ?

Avant de faire une configuration trop compliquée avec des restrictions, il faudrait repartir sur quelque chose de plus permissif : 

- Failed to load module "module-native-protocol-tcp" (argument: "auth-ip-acl=127.0.0.1;192.168.1.0/16"): initialization failed.  ==> je changerai pour autoriser toutes les connexions même en anonymes (sans l'argument auth-ip-acl), tu pourras affiner une fois que ton windows enverra sur ta gentoo.

Car avec cette erreur il arrête directement le serveur pulseaudio.

Et pour en revenir à l'outil paprefs, si tu l'utilises (ce qui dans un premier temps n'est pas plus mal) ne fait pas d'édition du fichier de configuration équivalent.

A chaque fois que tu fais tes tests sur le serveur pulseaudio de ta gentoo, fais un "journalctl -f /usr/bin/pulseaudio" pour être sûr de l'impact de tes opérations en temps réel (plus simple que de reprendre le fichier de log par la suite).

----------

## Chr0nos

j'ai tenté de modifier alors la j'ai:

 *Quote:*   

> Feb 10 21:06:14 localhost pulseaudio[30595]: [pulseaudio] module.c: Failed to load module "module-native-protocol-tcp" (argument: ""): initialization failed.

 

je ne conaisais pas journalctl merci pour l'info ^

voici mon fichier default.pa

 *Quote:*   

> #!/usr/bin/pulseaudio -nF
> 
> #
> 
> # This file is part of PulseAudio.
> ...

 

j'ai du desactiver le alsa-sink car il faisais planter pulseaudio aussi, ca deviens un vrais casse tête la

----------

## DuF

Effectivement il y a des options un peu dans tous les sens, je crois que tu fais pas mal de tests  :Smile: 

Pour alsa-sink de toute façon vu ton besoin tu ne semble pas en avoir besoin, donc tu peux le désactiver. Ce qui est valable pour tous les modules qui ne fonctionnent pas et dont tu n'a pas besoin.

Il faut peut être repartir d'un fichier épuré proche de la configuration par défaut. Voici le mien (si jamais tu n'a pas de backup) qui en local fonctionne par défaut et permet une écoute sur le réseau (j'utilise mpd qui envoie le son par le réseau vers le serveur pulseaudio pour fonctionner sans system-wide et avec l'tutilisateur mpd) :

```
#!/usr/bin/pulseaudio -nF

#

# This file is part of PulseAudio.

#

# PulseAudio is free software; you can redistribute it and/or modify it

# under the terms of the GNU Lesser General Public License as published by

# the Free Software Foundation; either version 2 of the License, or

# (at your option) any later version.

#

# PulseAudio is distributed in the hope that it will be useful, but

# WITHOUT ANY WARRANTY; without even the implied warranty of

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU

# General Public License for more details.

#

# You should have received a copy of the GNU Lesser General Public License

# along with PulseAudio; if not, write to the Free Software Foundation,

# Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.

# This startup script is used only if PulseAudio is started per-user

# (i.e. not in system mode)

.nofail

### Load something into the sample cache

#load-sample-lazy x11-bell /usr/share/sounds/gtk-events/activate.wav

#load-sample-lazy pulse-hotplug /usr/share/sounds/startup3.wav

#load-sample-lazy pulse-coldplug /usr/share/sounds/startup3.wav

#load-sample-lazy pulse-access /usr/share/sounds/generic.wav

.fail

### Automatically restore the volume of streams and devices

load-module module-device-restore

load-module module-stream-restore

load-module module-card-restore

### Automatically augment property information from .desktop files

### stored in /usr/share/application

load-module module-augment-properties

### Should be after module-*-restore but before module-*-detect

load-module module-switch-on-port-available

### Load audio drivers statically

### (it's probably better to not load these drivers manually, but instead

### use module-udev-detect -- see below -- for doing this automatically)

#load-module module-alsa-sink

#load-module module-alsa-source device=hw:1,0

#load-module module-null-sink

#load-module module-pipe-sink

### Automatically load driver modules depending on the hardware available

.ifexists module-udev-detect.so

load-module module-udev-detect

.else

### Use the static hardware detection module (for systems that lack udev support)

load-module module-detect

.endif

### Automatically connect sink and source if JACK server is present

.ifexists module-jackdbus-detect.so

.nofail

load-module module-jackdbus-detect channels=2

.fail

.endif

### Automatically load driver modules for Bluetooth hardware

.ifexists module-bluetooth-policy.so

load-module module-bluetooth-policy

.endif

.ifexists module-bluetooth-discover.so

load-module module-bluetooth-discover

.endif

### Load several protocols

.ifexists module-esound-protocol-unix.so

load-module module-esound-protocol-unix

.endif

load-module module-native-protocol-unix

### Network access (may be configured with paprefs, so leave this commented

### here if you plan to use paprefs)

#load-module module-esound-protocol-tcp

#load-module module-native-protocol-tcp

### Load the RTP receiver module (also configured via paprefs, see above)

#load-module module-rtp-recv

### Load the RTP sender module (also configured via paprefs, see above)

#load-module module-null-sink sink_name=rtp format=s16be channels=2 rate=44100 sink_properties="device.description='RTP Multicast Sink'"

#load-module module-rtp-send source=rtp.monitor

### Load additional modules from GConf settings. This can be configured with the paprefs tool.

### Please keep in mind that the modules configured by paprefs might conflict with manually

### loaded modules.

.ifexists module-gconf.so

.nofail

load-module module-gconf

.fail

.endif

### Automatically restore the default sink/source when changed by the user

### during runtime

### NOTE: This should be loaded as early as possible so that subsequent modules

### that look up the default sink/source get the right value

load-module module-default-device-restore

### Automatically move streams to the default sink if the sink they are

### connected to dies, similar for sources

load-module module-rescue-streams

### Make sure we always have a sink around, even if it is a null sink.

load-module module-always-sink

### Honour intended role device property

load-module module-intended-roles

### Automatically suspend sinks/sources that become idle for too long

load-module module-suspend-on-idle

### If autoexit on idle is enabled we want to make sure we only quit

### when no local session needs us anymore.

#.ifexists module-console-kit.so

#load-module module-console-kit

#.endif

.ifexists module-systemd-login.so

load-module module-systemd-login

.endif

### Enable positioned event sounds

load-module module-position-event-sounds

### Cork music/video streams when a phone stream is active

load-module module-role-cork

### Modules to allow autoloading of filters (such as echo cancellation)

### on demand. module-filter-heuristics tries to determine what filters

### make sense, and module-filter-apply does the heavy-lifting of

### loading modules and rerouting streams.

load-module module-filter-heuristics

load-module module-filter-apply

### Load DBus protocol

.ifexists module-dbus-protocol.so

load-module module-dbus-protocol

.endif

# X11 modules should not be started from default.pa so that one daemon

# can be shared by multiple sessions.

### Load X11 bell module

#load-module module-x11-bell sample=bell-windowing-system

### Register ourselves in the X11 session manager

#load-module module-x11-xsmp

### Publish connection data in the X11 root window

#.ifexists module-x11-publish.so

#.nofail

#load-module module-x11-publish

#.fail

#.endif

### Make some devices default

#set-default-sink output

#set-default-source input

```

Avec ce fichier là, même s'il semble ne plus pouvoir être opérationnel dans ton cas, cela devrait permettre de comprendre ce qui se passe. Ce qui donne la séquence :

1. remettre le fichier par défaut pour comprendre ce que fait pulseaudio

2. journalctl -f /usr/bin/pulseaudio (comme ça tu suis en live le comportement de ton serveur pulseaudio et tout ce qui lui convient pas à chaque fois que tu fais une modification)

3. relance du serveur pulseaudio => si tu as des soucis, c'est que tu as des fichiers cookie et consors qui faussent le truc, dans ce cas un ménage sera bienvenue. Tu peux regarder lors du démarrage de pulseaudio avec journalctl ce qu'il te dit pour identifier les fichiers concernés, tu peux t'inspirer de la documentation Arch qui est pas mal sur le sujet : https://wiki.archlinux.org/index.php/PulseAudio#Failed_to_create_sink_input:_sink_is_suspended (dis-toi que quand ça ne fonctionne pas, ça ne coûte pas grand chose non plus de tout effacer et de repartir zéro).

4. logiquement jusque là au mieux tu as du son en local, il faut faire en sorte que pulseaudio écoute sur le réseau. Essaye avec paprefs sans toucher au fichier de configuration, en activant l'écoute sur le réseau dans un premier temps en mode anonyme. 

5. Si ça fonctionne tu peux passer à l'écoute sur le réseau non plus en mode anonyme mais par authentification d'adresse IP.

Ce que j'indique là, c'est une approche car forcément de ton côté tu peux être tenté de faire plein d'essais et pulseaudio en tant que serveur permet beaucoup (trop ?) de choses.

Les conseils généraux sont de partir sur une base saine, telle que fournie par défaut. Avoir toujours un oeil sur le comportement de pulseaudio avec journalctl et ne faire des modifications qu'une par une et toute modification qui n'apporte rien, l'annuler en revenant en arrière dessus.

----------

## Chr0nos

je suis entierement daccord avec toi: repartir du début me semble la meilleur chose à faire, du coup j'ai repris ton fichier de config et juste dé-commenté le module tcp native

dans le log les choses se passse beaucoup mieux mais une erreur étrange subsiste:

 *Quote:*   

> févr. 11 03:23:32 stark pulseaudio[16027]: [pulseaudio] module.c: Loaded "module-dbus-protocol" (index: #23; argument: "").
> 
> févr. 11 03:23:32 stark pulseaudio[16027]: [pulseaudio] main.c: Got org.pulseaudio.Server!
> 
> févr. 11 03:23:32 stark pulseaudio[16027]: [pulseaudio] main.c: Démarrage du démon effectué.
> ...

 

ce SIGTERM ne viens pas de moi , un autre service pourais en être la cause ? (j'ai tronqué le log)

a l'heure actuelle plus aucun son (pas même en local) j'ai au cas ou conservé mon fichier de config

j'ai trouvé ca d'etrange sinon dans le log:

 *Quote:*   

> févr. 11 03:23:32 stark pulseaudio[16027]: [pulseaudio] control.c: Invalid CTL front:1
> 
> févr. 11 03:23:32 stark pulseaudio[16027]: [pulseaudio] alsa-util.c: Unable to attach to mixer front:1: Aucun fichier ou dossier de ce type
> 
> févr. 11 03:23:32 stark pulseaudio[16027]: [pulseaudio] alsa-util.c: Successfully attached to mixer 'hw:1'
> ...

 

----------

## DuF

En fait il semble que le sigterm concerne pulseaudio en mode démon, utilises-tu pulseaudio en mode démon (ou équivalent system-wide) ?

Je ne connais pas spécialement pulseaudio en mode démon (pas du tout en fait) du coup je pense que tu peux couper le démon et faire les tests avec le démarrage à la main de pulseaudio comme dans les exemples du wiki de archlinux.

Autre point, pourquoi as-tu besoin d'alsa de cette manière là ? La plupart des applications si elles sont compilées avec le flag pulseaudio savent envoyer à pulseaudio directement. Normalement avec le fichier de configuration que je t'ai poussé les modules alsa-sink et alsa-source ne devraient pas être chargés. Si tu fais journalctl -b | grep pulse tu auras tous les messages liés à pulse depuis le démarrage de la machine, avec le fichier de configuration plus haut, normalement les modules alsa ne devraient pas apparaitre.

----------

## Chr0nos

pour le moment j'ai ces uses la avec mon pulseaudio installé

 *Quote:*   

> [ebuild   R    ] media-sound/pulseaudio-4.0-r1  USE="X alsa asyncns avahi bluetooth caps dbus doc equalizer gdbm glib gnome gtk ipv6 libsamplerate orc qt4 ssl systemd tcpd udev webrtc-aec -jack -lirc (-neon) (-oss) -realtime (-system-wide) {-test} -xen" ABI_X86="32 (64) (-x32)" 0 kB
> 
> 

 

donc comme tu peu le voir pas de system-wide , en fait tu es en train de me dire que je peu utiliser pluseaudio en mode "standard" plutot que daemon pour faire cela ? et que ce sera donc le module rtp-receiver qui va lancer une instance de pulse pour lire le son ?

car comment ça se passe si le pc windows lit un son alors que le pc linux n'a pulse de lancé ?

pour alsa il me semble que c'est à cause de flashplayer que je suis obligé de le conserver, apres si je me trompe je peu le désactiver aussi

----------

## DuF

Pour moi oui tu dois pouvoir l'utiliser en mode standard d'après ce que je comprends de la documentation. Je n'utilise pas le module rtp-receiver mais pour les autres modules ça fonctionne ainsi; c'est ainsi que je fais pour que mpd communique en réseau avec pulseaudio. Après ce module est peut être spécifique.

Pour alsa pareil, j'ai systemd qui gère les services alsa suivants : 

```
genduf ~ # systemctl list-unit-files | grep alsa

alsa-restore.service                        static  

alsa-state.service                          static  

alsa-store.service                          static  

genduf ~ # journalctl -b | grep alsa-restore.service

févr. 12 14:49:50 genduf systemd[1]: Installed new job alsa-restore.service/start as 100

févr. 12 14:49:54 genduf systemd[1]: ConditionPathExists=!/etc/alsa/state-daemon.conf succeeded for alsa-restore.service.

févr. 12 14:49:54 genduf systemd[1]: alsa-restore.service changed dead -> start

févr. 12 14:50:11 genduf systemd[1]: Child 1965 belongs to alsa-restore.service

févr. 12 14:50:11 genduf systemd[1]: alsa-restore.service: main process exited, code=exited, status=0/SUCCESS

févr. 12 14:50:11 genduf systemd[1]: alsa-restore.service changed start -> dead

févr. 12 14:50:11 genduf systemd[1]: Job alsa-restore.service/start finished, result=done

genduf ~ # journalctl -b | grep alsa-state.service

févr. 12 14:49:50 genduf systemd[1]: Installed new job alsa-state.service/start as 101

févr. 12 14:49:54 genduf systemd[1]: ConditionPathExists=/etc/alsa/state-daemon.conf failed for alsa-state.service.

févr. 12 14:49:54 genduf systemd[1]: Starting of alsa-state.service requested but condition failed. Ignoring.

févr. 12 14:49:54 genduf systemd[1]: Job alsa-state.service/start finished, result=done

genduf ~ # journalctl -b | grep alsa-store.service

```

Et pour pulseaudio, les modules alsa sont off au global : 

```
genduf ~ # grep alsa /etc/pulse/*

/etc/pulse/default.pa:#load-module module-alsa-sink

/etc/pulse/default.pa:#load-module module-alsa-source device=hw:1,0

```

Mais disponibles pour le user (ce qui permet d'être opérationnel pour le lecteur flash) :

```
grep alsa /home/toto/.config/pulse/*

/home/toto/.config/pulse/ce2843f18e3ec59f7f48b9f1514348ad-default-sink:alsa_output.pci-0000_00_1b.0.analog-stereo

/home/toto/.config/pulse/ce2843f18e3ec59f7f48b9f1514348ad-default-source:alsa_output.pci-0000_00_1b.0.analog-stereo.monitor

```

Du coup, par rapport à ta question si pulse est démarré ou pas, ta machine tu l'utilises toujours avec une interface graphique ou l'utilises-tu des fois seulement en mode console ? Vu que pulseaudio est démarré en général automatiquement par les IHMs si tu es en console il faut effectivement penser à le démarrer (pulseaudio --start tout bêtement).

----------

## Chr0nos

alors j'ai repassé pulseaudio en mode "standard" , activé le module rtp recv (via le fichier de config car je n'ai pas l'impression que papref change quoi que ce soit :s)

j'ai de nouveau du son sur le pc gentoo serveur

pour voir pourquoi windows ne me lis aucun son avec le serveur j'ai donc décidé d'utiliser mon second gentoo (installé sur le meme pc que windows 7)

et je suis donc allé voir dans ses logs apres avoir configuré le rtp-send et une destination=192.168.1.1 et la miracle : mes logs sont litéralement floodé de ceci:

 *Quote:*   

> [pulseaudio] sap.c: sendmsg() failed: Connection refused

 

hors j'ai copié le cookie de mon pc gentoo serveur vers le gentoo client via scp

(j'utilise le client uniquement en lignes de commandes vu qu'il n'a pas de WM ni de serveur graphique (ne sers que pour des calculs cuda...))

je me demande donc une chose: le module rtp recv fait il bien son boulot ?

car quand je fais un 'nap localhost' je n'ai aucun port nouveau ouvert

de mon coté j'ai aussi:

 *Quote:*   

> stark pulse # systemctl list-unit-files | grep alsa 
> 
> alsa-restore.service                        static  
> 
> alsa-state.service                          static  
> ...

 

j'ai vu que le site de pulseaudio est de nouveau en ligne, je me base sur leurs doc: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index39h3

mais cela reste assé enigmatique pour moi   :Shocked: 

j'ai meme ça dans mes logs

 *Quote:*   

> févr. 13 22:58:58 stark pulseaudio[15644]: [pulseaudio] ltdl-bind-now.c: Failed to open module module-esound-protocol-tcp.so: module-esound-protocol-tcp.so: Ne peut ouvrir le fichier d'objet p...ier de ce type
> 
> févr. 13 22:58:58 stark pulseaudio[15644]: [pulseaudio] module.c: Failed to open module "module-esound-protocol-tcp".
> 
> févr. 13 22:58:58 stark pulseaudio[15644]: [pulseaudio] module-gconf.c: pa_module_load() failed
> ...

 

et le fichier recherché n'existe nul part sur ma machine

edit: j'ai trouvé ca sur la doc de PA:

 *Quote:*   

> module-rtp-send: The "destination" argument was renamed to "destination_ip".
> 
> module-rtp-send: New module argument: source_ip. On a multi-homed system, it may be desirable to use RTP only on a specific interface. The interface can be selected by specifying the source IP address.

 

dans le changelog de la 4.0, j'ai renomé en consequence le destination_ip dans mon fichier de config mais aucun changement

edit2:

j'ai enfin trouvé et ca marche !!

en fait il ne falais pas passer par RTP qui lui prends plutot le probleme "à l'envers": pour lui les client se connectent à un serveur qui DIFFUSE, hors moi je voulais que le serveur "revoive' donc j'ai viré les modules rtp

et ensuite:

dans le default.pa

 *Quote:*   

> 
> 
> load module-native-tcp auth-anonymous=1
> 
> 

 

ensuite dans le client.pa

 *Quote:*   

> 
> 
> default-server= 192.168.1.1
> 
> 

 

tout le reste du fichier commenté

ca marche au poil !

poid du flux sur le reseau: ~200ko/s : ca va

y'a pas à dire pulseaudio est une vraie usine à gaz mais qu'es qu'elle est complete cette usine !

du coup je suis ravis , je n'ai plus qu'a config correctement pulseaudio sous le windows 7 (car oui c'était juste de gentoo à gentoo la :p)

----------

## DuF

Au final, l'important c'est que tu comprennes ce qui te permets d'avoir ta configuration opérationnelle  :Smile: 

Il semble donc que le gros du travail que tu as réalisé se décompose en 2 parties : 

- simplifier et n'utiliser que le strict nécessaire

- clairement définir ce que tu souhaites faire.

En regardant l'ensemble de tes messages à partir de ton premier post, on peut dire que tu as touché à pratiquement toutes les options possibles de pulseaudio  :Smile:  Alors que j'ai l'impression que ta configuration maintenant est relativement simplifiée.

Le mode esound (module-esound-protocol-tcp.so) vu ton besoin tu t'en fou, commentes-le dans ton fichier pour éviter d'avoir un log inutile.

Je ne sais pas si pulseaudio est une usine à gaz mais il se laisse facilement transformer en usine à gaz, il permet tellement de choses que ça peut vite devenir n'importe quoi. Mais avec les applications qui maintenant gèrent pulseaudio, c'est vraiment mieux qu'avant et il y a un plus à l'utiliser (je n'aurai sans doute pas dit ça il y a quelques temps)

NB : RTP ne prend pas le problème à l'envers, il ne répond juste pas à ton besoin, mais bon fallait le deviner ton besoin  :Wink: 

----------

## Chr0nos

ouaip je suis assé d'accord avec toi, j'ai donc commenté la ligne inutile

j'ai modifié la config sous le windows aussi, j'ai vu que l'os m'a demandé d'authoriser une conection sortante: je me suis dit "jackpot !" mais ... non pas de son

je pense que cela vient de la "source"

j'ai donc fait un:

 *Quote:*   

> 
> 
> cd c:\pulseaudio\bin
> 
> pactl.exe list sources | more
> ...

 

et la je n'ai pas trouvé ma source audio (la seule branchée: mon écran avec une prise mini-jack derriere donc son via le HDMI de la carte graphique (deja testé: il marche))

les seules sources que les commandes m'affichent ce sont celles du pc distand (le serveur gentoo)

étrange non ? :s

----------

## DuF

Ce qui est sûr, c'est que vu que ça fonctionne de ta gentoo à gentoo, le soucis viens de la conf sur le windows, soit au niveau du pulseaudio soit de l'OS.

Si j'ai bien compris, tu veux sortir ta source de son local du windows (musique, jeu, etc.) vers le sink (output) du pulseaudio du gentoo ?

----------

## Chr0nos

c'est exactement ça

j'ai aussi config mon laptop (linux mint) vers mon serveur gentoo: ca marche au poil

le probleme viens bien de ma config sous windows

j'ai aussi remarqué que le dernier build de pulseaudio trouvable pour windows est la version 1.1

je me demande donc si il serais utile que je compile moi meme (je ne sais absolument pas comment faire xD) la version 4.0 par exemple depuis un crossdev

coté terminal sous le windows j'ai ces erreures:

pulsecore/core-utils.c: Secure directory creation not supported on win32 (celle la me semble grave car répétée 6 fois)

pulsecore/pid.c: stale pid file, overwriting (osef)

pulsecore/core-util.c: failed to allocate shared memory pool. falling back to a normal memory pool (je supose que ca empeche le multi user sur cette machine mais je m'en moque un peu)

daemon/main.c: failed to load directory

----------

## DuF

Déjà en local sur un même linux, il faut des fois recompiler pour qu'un client discute avec le serveur alors oui il y a de fortes chances que tu doives aligner ta version sur le windows avec ton serveur pulseaudio.

C'est rassurant que ton laptop fonctionne aussi, ça délimite bien le problème et évite de toucher au reste.

----------

## Chr0nos

bon alors j'ai recu mon systeme 5.1 aujourd'huis, et je l'ai configuré avec pavucontrol sur la machine gentoo serveur : ca marche nickel

en revanche les client envoient du stéréo au lieu du 5.1 << edit: resolu (en meme temps que le serveur à fonctioné en 5.1, il falais ajouter "channels=6" dans /home/adamaru/.mplayer/config ( je testais avec mplayer))

j'ai tenté de modif dans daemon.pa mais vu que je lance pas pulseaudio en mode serveur je doute que ce fichier soit pris en compte << en fait si (edit)

sinon je cherche aussi comment compiler pulseaudio sous windows^

edit: je cherche aussi à changer les volumes des retour arriere qui sont carément trop faibles

edit2:

en fait quand je fais : pactrl.exe list sources

je n'ai pas ma carte son (locale) sur le client, je suppose donc qu'il manque un module pour la détecter, mais la grande question c'est: le quel ?

----------

## DuF

A priori ça avance pas si mal  :Smile: 

pour le pactl list sources sur le windows il faut sans doute voir ce que pulseaudio détecte sur le windows. Est-ce qu'il te sort qqchose au moins quand tu fais pactl stat ou pactl info ?

----------

## Chr0nos

alors détrompe toi, cela va de mal en pire  :Smile: 

je suis allé sur le channel irc de pulseaudio , et la on m'a tout simplement dit que pulseaudio sous windows ne sais pas "écouter" une carte son, et encore moin en creer une virtuelle pour en recuperer le flux

donc je me suis lancé dans la conception d'un soft en C++/Qt5 pour faire le boulot via QAudioInput (étant donné que QAudioRecorder ne fais RIEN (pas meme un message d'erreur, non non il me dis que touuut baigne )) dont le but sera de se connecter au module-native-protocol-tcp de pulseaudio sur le port 4713 (par defaut) puis d'y balancer le flux en audio/pcm

pour le moment:

- je détecte les devices

- il est possible de choisir quel sortie écouter

- on peu lancer l'enregistrement du son vers un fichier (pas encore de gestion du tcp)

probleme:

- pas moyen de relire le fichier enregistré (pourtant non null, et contenant apparement des données viables) : aucun player ne le reconais (pas d'entêtes  puisque lu depuis un QIODevice*)

donc voila, apparement aucun moyen de faire ca avec pulseaudio sous windows, il ne l'ont fait que pour faire du linux->windows, pas l'inverse

apres si des gens se sentent de me filler un coup de main je suis preneur xD voila ce qui coince pour le moment: http://pastebin.com/4b1YaQzh (alentours de la ligne 36 apparement) , je peu fournir la totalitée du code au besoin

----------

## DuF

oula... déjà tu as bien fait d'aller faire un tour sur le channel irc car on aurait pu rester longtemps sur l'idée que c'était réalisable. Du coup c'est moche que la version windows soit limité ainsi même s'ils ont sans doute de bonnes raisons.

Et pour moi, pas de windows ni de Qt (gnome addict  :Smile:  ) et une vraie bille en développement   :Laughing:  .

Qu'est-ce que je pourrais faire.... te dire : "bon courage"  :Smile: 

----------

## Chr0nos

merci  :Smile: 

la raison de l'absence de détection du device: "persone n'a voulu faire ce taff la"

en gros ils préfèrent coder des filtres et des equaliseurs de malade que de faire un module de détection des devices sous windows, logique  :Smile: 

----------

## Chr0nos

bon il y à du nouveau:

je me suis penché sur la gestion des cartes son avec pulseaudio et de leurs écoute et j'ai obtenu de bons résultats, pour le moment j'arive à:

- écouter la plupart des périferiques de mon ordi (windows)

- envoyer ce que j'écoute vers: fichier.pcm / autre périferique local / flux reseau tcp

en revanche pulseaudio ne semble pas aimer ce flux tcp en audio/pcm que je lui envoi à la barbare (pas de protocole, juste un flux) et me sors l'erreur suivante:

 *Quote:*   

> févr. 21 22:49:51 stark pulseaudio[22730]: [pulseaudio] pstream.c: Received SHM frame on a socket where SHM is disabled.
> 
> 

 

sur le channel de PA : personne ne sais ou trouver de la doc sur le module-native-protocol-tcp de pulseaudio (au quel je tente de me connecter) et qui semble utiliser la libpulse (ce qui serais donc un frein pour moi)

je me demande donc si il existe un module capable de supporter un flux sans protocole anexe (au pire je dois bien pouvoir bricoler une gestion de proto pour peu que j'ai la doc sur le protocole requis)

donc voila, nous sommes à deux doigts d'une solution pour la lecture de son windows->linux avec pulseaudio

évidement quand il sera terminé je publirais le code source de mon application (car c'est toujours meilleur quand c'est gratuis, et encore plus quand c'est opensource  :Very Happy: )

----------

## DuF

Je suis perplexe quand à l'absence de doc sur le module tcp.... en dehors du channel PA as-tu essayé sur la mailing list, il y a peut être des têtes dessus qui ne trainent pas sur le channel et qui seraient à même de te répondre.

En tout cas félicitations pour ce que tu as fait jusqu'ici et courage pour la suite car tu es vraiment proche du but.

----------

## Chr0nos

je n'ai pas testé la mailing list, je ne pense pas le faire étant donné ou j'en suis:

j'arrive à envoyer mon flux audio (en audio/pcm) dans mon socket tcp de cette maniere:

pc windows (lis le son) -> mon prog client (écoute la carte son) -> flux tcp -> programe serveur (pc gentoo) -> lecture du flux sur le périferique de mon choix

les seuls problemes qui subistitent actuelement:

1: je suis limité à du stéréo (pas de 5.1 pour le moment mais ca viendra peu être si je me debrouille avec virtual audio cable et que je créé un device à 6 cannaux)

2: le son est insuportable: plein de micro lags (comme si il manquais des trammes alors que non) ce qui rends la chose pour l'heure inutilisable, je cherche une solution, un buffer n'est pas envisageable car il génererais un "lag" par raport au son, hors un lag de son dans un jeu... je ne me vois pas tirer une balle et entendre le bruit du tir une seconde apres xD

3: si le serveur crash ou coupe la connection: le client plante à coup sur (surement une sombre histoire de pointeur mais à retrouver dans tout ce bazard   :Shocked:  )

apres la bonne nouvelle c'est que le serveur est over léger  : pas d'interface (serveur quoi) (et moin de 100 lignes de code au total) , de plus il est portable windows/linux/mac os (merci Qt)

le client quand à lui dispose d'un gui pour que n'importe qui sache s'en servir

pour le module tcp de pulseaudio: la raison est simple en fait: ils veulent que l'user passe par libpulse : je m'y refuse , mon systeme permet de faire totalement sans pulseaudio (ça plaira a ceux qui n'aiment pas ce truc) et se connecte au lecteur de son par defaut de la machine (si non spécifié)

----------

## Chr0nos

bon il y à du nouveau:

- plus de problemes de sons

- serveur stable

- possibilitée de passer sur 6 canaux (ou +)

en renvanche le serveur fais bien plus de lignes de code que prévu :p (sécuritée oblige)

voici le git du serveur: http://code.google.com/p/audio-transfer-server/

requier Qt5 (pour le support de pulseaudio) , en Qt4 : juste alsa et qtmultimedia

je posterais le client dans la semaine (encore un sombre bug qui fais crash à coup sur le client quand je fais un refresh :/)

donc voila, que de bonnes nouvelles, la chose n'avais rien d'impossible comme l'équipe de pulseaudio voulais me le faire croire  :Smile: 

----------

