Tanu Kaskinen schrob:
> On Fri, 2010-04-16 at 21:02 +0200, Jan Braun wrote:
> > *** Now is your chance to say "that's insane, and we don't support it"
>
> I can't say it's insane, otherwise I'd be admitting that I've been
> insane in the past :)
Well, you could say you've seen the error of your ways. ;)
> But we still don't support it. (Well, that depends
> on what "support" means, but since you've successfully been using the
> system mode, and you think we don't support it, I guess your definition
> of "support" means something like "the use case is important to us".)
Exactly.
> > 3) per-user-pulseaudio, one with access to the hw, other users send to
> > that one via network/localhost. Also mixes twice, and (almost)
> > every sound data is pushed through lo. Unless PA recognzes lo and
> > optimizes for that case? Also needs that one user to be logged in
> > always (that's easily done, however).[2]
>
> My suggestion is basically the same as your option 3, without the double
> mixing and tcp overhead (I'm not sure whether using the loopback
> interface has much more overhead than unix domain sockets, though - you
> still won't be able to use shared memory for audio transport).
Hmm, why not? I've set up PA as you describe (except for the additional
auth-group parameter), and PA is creating entries in /dev/shm , even for
other users than "albert".
> Let's say your always-logged-in user, [...]
> That should be it. I didn't test any of this, so this probably doesn't
> work, at least at the first try.
It did (well, almost.. I also had to disable PA auto-exiting, otherwise
it stopped mysteriously working after a short time ;)
> Wasn't this supposed to be a single-person system?
It currently is. But I'd like to be able to allow others access in the
future. Sorry if that was unclear.
> My suggestion should
> be safer than the system wide mode, but my suggestion doesn't work
> perfectly with multiple real persons who don't all use albert's
> pulseaudio. It may work well enough, though.
Yep, this is exactly what I was looking for. "not perfecly" because
consolekit may be confused about whether albert should be considered
logged in, I guess? Hmm, I'll see...
> > So, do you think my scenario is valid?
>
> At least I don't see your scenario as an important case to support.
If it works by copying around pulse-cookie (or even better, auth-group),
that's good enough for me. I just didn't like the big warning signs on
system mode.
> Yes, this is very similar to the system wide mode. The main difference
> is that when creating new users, they by default use their own
> pulseaudio instances.
Yes, and just what I wanted. But the behaviour of new users can be
easily adjusted by modifying /etc/pulse/client.conf .
So how exactly is this better than system mode? Or isn't it?
I'm confused.
But thanks for your detailed how-to,
Jan
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100417/69b5fdd1/attachment.pgp>
