[pulseaudio-discuss] Sharing logged in users instance over TCP better than systemwide daemon?

[Maarten Bosmans]

2011/12/10 Graeme Pietersz <graeme.pietersz at gmail.com>:
> I want a shared PC on a home LAN to be able to play a stream uninterrupted through one sound card (connected to a decent amp and speakers in the sitting room) while allowing other users to login and use another sound card if they wish.
>
> I was planning to use a system-wide daemon, but after reading the warnings about it, I wondered if this was a better solution:

Actually, in this case I think a system-wide daemon is the right
setup. Some of the disadvantages (e.g. no shm) don't apply of the only
thing you want is to make a sink available over the network.

> Following the suggestion in this thread:
>
> http://forums.fedoraforum.org/showthread.php?t=190954
>
> Have an auto logged in user that starts pulseaudio with:
>
> load-module module-native-protocol-tcp
>
> in its ~/.pulse/default.pa
>
> all other users have:
>
> default-server = 127.0.0.1
>
> in  ~/.pulse/client.conf
>
> That way any local user or anyone on the LAN can play a stream though this machine.
>
> Is this better than a system-wide daemon in any way? Is it better supported?

I would not recommend this setup. This is just simulating a
system-wide daemon with a separate user daemon and has all the same
disadvantages. Then why not simply use the system-wide feature?

> Obviously, allowing any user access is not a security issue as that is what I want (it would be good to restrict network access to the microphone though, but its not essential).

The best setup I can think of is to run a system-wide daemon on
startup with module-native-protocol-tcp loaded and a per-user daemon
in the default setup. You should setup both daemon's config files
(/etc/pulse/{system,default}.pa respectively) such that instead of
running module-udev-detect, you only load a module-alsa-sink (and
perhaps a source) for the right soundcard, so that each daemon only
has sinks and sources for the card it needs. (thereby also solving the
microfone eavesdropping problem)

There could be a problem with the dbus bits of pulse, but I think that
those are solved in git master.

> Latency an issue as it will mostly be used for music and broadcast streams. Having an automatically logged in user is also not a problem as I want one shared user anyway.

There shouldn't be a latency difference between per-user and
system-wide. (for network streams and in case everything is setup
correctly, primarily rtkit)

That being said, just for playing music in your home, latency
shouldn't be a big issue, right?

Maarten

> Graeme
>
> --
> Graeme Pietersz
> http://moneyterms.co.uk/
> http://pietersz.co.uk/
> http://twitter.com/gpietersz
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss