[pulseaudio-discuss] Sharing logged in users instance over TCP better than systemwide daemon?
Maarten Bosmans
mkbosmans at gmail.com
Thu Dec 22 14:09:10 PST 2011
2011/12/22 Graeme Pietersz <graeme.pietersz at gmail.com>:
>
>> Message: 1
>> Date: Wed, 21 Dec 2011 23:24:50 +0100
>> From: Maarten Bosmans <mkbosmans at gmail.com>
>> Subject: Re: [pulseaudio-discuss] Sharing logged in users instance
>> over TCP better than systemwide daemon?
>> To: General PulseAudio Discussion
>> <pulseaudio-discuss at lists.freedesktop.org>
>> Message-ID:
>> <CA+CvcKT3tPcUomU=XeCXURgtikFCJM4XeK25MpLE_J8Tc37wDw at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> 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?
>
> I have got it running this was in the meantime. I did it because of all
> the warnings about it being unsupported: "it is explicitly not designed
> for it, you are on your own if you use it"
>
> Should I switch to a system wide daemon urgently or at leisure? Any huge
> problem with what I am doing (given that that user is always logged in
> anyway)?
Not really, but the extra user is a bit of a hack and system-wide fits
your use case nicely. I don't know which distro you are on, but at
least on Debian/Ubuntu the pulseaudio package comes with a nice init
script and pulse/pulse-access users configured for system-wide mode.
Conceptally a system daemon ran from an /etc/init.d script is a better
fit to make a sound server available than a auto-logon user.
>> > 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)
>
> I am a bit confused by this. Why does the per-user daemon need the
> sound card as a sink? I imagined it would see a network sink.
I understood your use case to be a separate high-quality soundcard for
living-room sound that should be made available to all machines on the
network and the integrated soundcard on the mainboard for local sound
for logged in users. Those are the two soundcards I was speaking of.
> Is there any chance of this ever being a supported way of doing things?
> Users like me really need some recommended way of doing this. Its not
> an uncommon requirement (as many previous posts on this mailing
> list, various distro forums, etc. show).
>
> Ideally I would like to be able to do this as easily as I can share a
> printer or a directory (i.e. tick boxes in a GUI). At the moment its
> harder than configuring most web servers or RDBMSs.
>
> Thanks for your help and I will try doing it this way.
>
>>
>> There could be a problem with the dbus bits of pulse, but I think that
>> those are solved in git master.
>
> So I would need to compile and install that? I am not really
> comfortable with replacing something that is provided by default by
> the distro and on which other things depend.
Not needed, as Tanu said, there should be no dbus problems when
running system and per-user daemons at the same time (so perhaps this
is a reason system-wide is better), so you don't need a recent version
with the dbus fix.
>> > 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?
>
> Yes! I left out a "not". Sorry.
>>
>> 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
>>
>>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
More information about the pulseaudio-discuss
mailing list