[pulseaudio-discuss] Random PA Deployment Idea

[CJ van den Berg]

On Sun, Dec 17, 2006 at 10:12:20PM -0600, Jerry Haltom wrote:
> So, I finally managed to get PA up and running on my Ubuntu box, using
> the distributed packages. Took me awhile get get Alsa working and
> everything, but did manage to succeed. Got it set up on some remote
> boxes, and been having fun forwarding audio around my apartment.

It should've just worked "out of the box". Could you comment on what didn't
work first try? I'd like to get the packages working smoothly as possible in
the default configuration.

> I've run into one problem though. PA supports moving a stream between
> sinks live, but only when those sinks exist within the same PA daemon.
> This is great for those... few cases where people have multiple sound
> cards. How many people have multiple, and care?

I have several sound cards in one of my PA boxes, with outputs going to
different rooms of the house. With the additional manageability that PA
offers I think these sort of scenarios are potentially quite common.  There
are several other sink types besides real hardware anyway, so it does make a
lot of sense.

> Me, I have a lot of systems. I have one on my stereo, one on my desktop.
> Laptop over there. Another desktop. I want to forward live streams
> between different PA instances... and this got me thinking.

You can do this now, no problem. You need to have a look at the tunnel
module. That module will give you a local sink that forwards everything sent
to it to a remote PA instance. That way you can do local stream transfer and
have it end up going remote.

> Right now you have two real options, a per-user PA daemon and a
> per-system PA daemon. They both solve slightly different problems. I
> personally prefer the system wide PA daemon. It's obviously the only
> real way I can share my audio devices. I don't really understand why
> per-user is recommended.

AFAIK per-user is really only recommended because of the shared memory
interface; because it's potentially a little lower latency. Besides that,
the only real reason for recommending per-user are the security implications
of any system daemon. I personally don't see much risk at all in that
though, especially if you disallow module loading.

> Still though, I can't move live streams between servers. So after
> thinking awhile, I came up with what might be a good configuration for
> this... perhaps the ideal configuration for the standard desktop.
> 
> First, you have a "system" PA instance. It runs /etc/pulse/system.pa. It
> loads module-hal. Detects local devices. It's goal is to manage access
> to LOCAL devices. A single wrapper around them. In this PA instance one
> could enable zeroconf-publishing and tcp access and various ACLs.
> 
> Second, you have a "user" PA instance. Each user who logs into the
> desktop gets one of these. It doesn't talk to hardware. It loads a
> module which detects all the local sources and sinks, by talking to the
> local PA daemon. It can also browse the network for zeroconf advertised
> sinks (ignoring the local ones if they are advertised.)
> 
> What you have here then is one system instance and many user instances.
> Multiple users can login and access to the hardware can be multiplexed
> through the system PA. Clients would not be able to do advanced
> operations on the system PA unless they had certain rights. Can't move
> streams, etc. The user PA would be 100% under control of the user. He
> could move streams between it's sinks. This would mean he can make his
> local PA move a stream between the local system PA and a remote system
> PA. This is very nice. Policy gets applied at the appropiate places.
> 
> As for zero-copy of data, not sure. I suspect the two PAs could
> communicate with shm still.
> 
> This would be an ideal default desktop install and not require any
> configuration to achieve the desired result. What do you all think?

Each additional intermediate PA instance adds latency, which is really not
ideal. Besides that, the per-user PA instances in your scenario don't do
anything that the system instance couldn't do, so there's not much point in
having them.

What would make more sense IMHO, would be zeroconf detection of other PA
instances *in the server* instead of (or perhaps in addition to) in the
client libraries. That way, when one PA instance detects another on the
network it could automatically create a tunnel sink which would allow
dynamic stream transfer to the remote instance.

-- 
CJ van den Berg

mailto:cj at vdbonline.com
  xmpp:cj at vdbonline.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20061218/1a6b5bb1/attachment.pgp>