Re: [pulseaudio-discuss] system-wide daemon

[Luke Yelavich]

On Wed, Feb 17, 2010 at 12:25:27PM EST, Lennart Poettering wrote:
> On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-disc...@trk.nickurak.ca) 
> wrote:
> > Incidentally, this seems to be the same use case that vision-impaired users
> > were dealing with recently: How can system-level processes inject their
> > inputs to the speakers without a system-level pulseaudio daemon sharing that
> > hardware?
> 
> Nope, there should not be a system-level process generating the speech
> audio. It should be a user/session process. Now, unfortunately the
> current solutions are mostly based on system daemons, but that doesn't
> mean that that would be the "correct" way to handle these
> things. Because it is not.

There are a group of us gradually moving everything a11y, including speech 
output/audio into user sessions, and as discussed last month, an idle like user 
that consolekit/udev knows about is needed for those speech/audio processes 
that users want to use so they can get a text console login screen to be 
usable. Should nobody else get to this in the coming months, this is on my 
agenda.

Luke
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 18:49, Jeremy Nickurak (pulseaudio-disc...@trk.nickurak.ca) 
wrote:

> A question about the console-kit approach, where the user physically near
> the sound hardware is the person that gets to use it...
> 
> A favorite trick of mine is to ssh into a machine, and use the sound
> hardware there to announce some kind of event. It might be an alarm to wake
> up a family member, or a remotely-generated event alert. It might not be
> SSH, it might be a cron job, or a CGI...
> 
> Assuming I'm the administrator of the machine, how can I pull off this trick
> in the context of console-kit? If it's even possible, it sounds like I'd
> have to suspend the existing pulseaudio connection by assigning rights to a
> "virtual console" of some kind, which would then have the opportunity to use
> the audio device until it released it.

If you are root you can do anything you want, including doing the
baddest things to your audio devices you want.

And as mentioned a gazillion of times in recetn distros even non-root
users can do this, regardless whether they are logged in or not, if
they are a member of the "audio" group.

> Incidentally, this seems to be the same use case that vision-impaired users
> were dealing with recently: How can system-level processes inject their
> inputs to the speakers without a system-level pulseaudio daemon sharing that
> hardware?

Nope, there should not be a system-level process generating the speech
audio. It should be a user/session process. Now, unfortunately the
current solutions are mostly based on system daemons, but that doesn't
mean that that would be the "correct" way to handle these
things. Because it is not.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 16, 2010 at 10:17 PM, Lennart Poettering
 wrote:
> On Tue, 16.02.10 20:48, Markus Rechberger (mrechber...@gmail.com) wrote:
>
>> Lennard, don't spread nonsense around, if you have raw access to a camera 
>> there
>> might be the possibility to update the firmware and damage the device.
>> If you would have little experience with hardware you should know about that.
>> Your ACL/libusb restriction won't make this situation better it's
>> still a security risk.
>> Although just drop libusb as an example.
>>
>> Markus
>
> Marcus, then you better run quickly and complain to the udev folks,
> because they have been shipping udev with libusb devices accessible to
> console users sine about forever. Just plug in a USB scanner on a
> reasonably new Linux machine and run "ls -al /dev/bus/usb/*/*". Then,
> look out for the "+" in the permissions column and run getfacl on that
> file, and you'll see that the logged in user may access the device
> node.
>

Sure but this doesn't mean that it's right and is a security issue.
It's like making CPU levels obsolete just because someone made
the mistakes to run everything at Kernellevel.
Almost all available USB TV Tuners use to run with a firmware nowadays,
even by loading the wrong firmware into a chip a chip can blow up.
If every user has the possibility to access devices at a raw level
(not at a defined
API level) ...everyone can do that.

> But all of this has nothing to do with PA.

Indeed, but this ACL example came up by you guys, so you should better
learn that
this is not always the correct way. With your example this even turns
out to be a security risk.

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 16.02.10 20:48, Markus Rechberger (mrechber...@gmail.com) wrote:

> Lennard, don't spread nonsense around, if you have raw access to a camera 
> there
> might be the possibility to update the firmware and damage the device.
> If you would have little experience with hardware you should know about that.
> Your ACL/libusb restriction won't make this situation better it's
> still a security risk.
> Although just drop libusb as an example.
> 
> Markus

Marcus, then you better run quickly and complain to the udev folks,
because they have been shipping udev with libusb devices accessible to
console users sine about forever. Just plug in a USB scanner on a
reasonably new Linux machine and run "ls -al /dev/bus/usb/*/*". Then,
look out for the "+" in the permissions column and run getfacl on that
file, and you'll see that the logged in user may access the device
node.

But all of this has nothing to do with PA. So please go away, and
complain elsewhere.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Thu, Feb 11, 2010 at 12:29 AM, Lennart Poettering
 wrote:
> On Wed, 10.02.10 09:59, Markus Rechberger (mrechber...@gmail.com) wrote:
>
>> this is another wrong assumption, libusb uses raw USB access, if every
>> user would have access
>> to USB some devices might be damaged.
>> Sane would need to be serverbased, full raw access to the usb bus
>> would seriously be a security
>> risk (imagine RAW USB access to a USB harddisk).
>
> This is nonsense. Since ages we by default add ACLs for the console
> user for libusb devices for cameras, scanners, and so on. That too
> works via udev-acl.

Lennard, don't spread nonsense around, if you have raw access to a camera there
might be the possibility to update the firmware and damage the device.
If you would have little experience with hardware you should know about that.
Your ACL/libusb restriction won't make this situation better it's
still a security risk.
Although just drop libusb as an example.

Markus

>
> You are spreading FUD and lies. You are annoying. And are stealing my
> time. I'd prefer if you'd waste other people's time, and stop lighting
> up the flames of this flamewar over and over again.
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[David Henningsson]

Lennart Poettering wrote:
> On Wed, 10.02.10 07:14, David Henningsson (launchpad@epost.diwic.se) 
> wrote:
> 
>> But printers are more of a system-wide resource, and for some use cases,
>> so is the soundcard. 
> 
> This is nonsense. I am not sure how your ears are constructed, but on
> a multiseat system if you want to share a soundcard between two seats,
> where would you put the speakers so that the two users have the same
> distance from L and R and they are on the left and the right side? I
> mean, those users would have to sit on top of each other or detachable
> ears or something.

Detachable ears seems cool, although I'd prefer headphones. Anyway,
multiseat wasn't the use case I was talking about here, I was more
thinking of the "use computer as combined desktop workstation and
independent media player for the kitchen" use case.

> We discussed this with a couple of folks long time ago, and decided
> that some reasources are per-seat resources, and should be configured
> like that. Those devices are keyboards, mice, screens, sound cards,
> webcams and a couple of others. the UDEV_ACL=1 property in the udev
> tree marks most of them. This discussion was mostly done on the udev
> level btw, it is only indirectly related to PA.
> 
> Now, in some non-standard cases it might make sense to have the access
> rules deviate from this default, but those are the exceptions, not the
> common cases. And that means that you configure it that way, but the
> default will be the safe, common case, not the dangerous uncommon
> case.

Exactly.

> BTW, I really do not know why I am even responding, 

Neither do I. If I knew what makes you respond to some posts and leave
others behind, I would have used that knowledge to make you respond to
the alsa-plugins patch I suggested earlier [1].

> Do you know this Google thing? It's kinda
> cool, you should try it.

Never heard of it. I'll go search for it and see if I find something.

>> And then, sharing makes sense. If another user is
>> allowed to print a document while I'm logged in, why shouldn't he be
>> able to play a sound? So would then the solution be to run PA as a
>> system-wide daemon, and possibly assign soundcards to it via udev?
> 
> Right, allow every user to listen into all voip calls, 

You're mixing the use cases up. The soundcards you use to make voip
calls, are not necessarily the ones you want to share with other users.

> Lemme guess, you disable access control to your X11 screen too?

There are use cases for that as well, but we can leave them out for now.

// David

[1]
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-February/006471.html
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[David Henningsson]

Lennart Poettering wrote:
> On Tue, 09.02.10 22:52, David Henningsson (launchpad@epost.diwic.se) 
> wrote:
>> There are just too many people for where the ordinary PA setup (all
>> soundcards are of exclusive use to the person logged into the current X
>> session) is not acceptable, and worse, it isn't easy for them to either
>> reconfigure PA, or replace PA, with something that suits their
>> needs.
> I doubt the "too many". 

Let's conclude that our milages vary, then.

> The handful of people coming up with this
> from time to time is fairly minimal, I you allow me to say so.

Oh. Most of the people don't complain here. They go googling and find
solutions such as stacking PA on top of dmix, using alsa-plughw directly
from an application, remove all traces of PA from the system, etc etc,
with various degree of success. Sometimes the information is meant for
another distro or version, and they end up messing up more than they fix.

Anyway, reading this thread has been helpful and I got a few pointers.
I'll see if I can sum it up in one page to make the information more
accessible.

// David

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

I did that originally.  The problem is that I'm building Vinux ISOs on
Ubuntu using remastersys, and I'd have to modify ubiquity to change
the default user groups.  The result is that after isntalling Vinux,
Orca doesn't come up talking.  Now, I may go modify ubiquity, but I'm
more familiar now with PA than ubiquity, and I took a shortcut.
Long-term, I'll probably figure out how to change ubiquity to change
default user groups.  However, since all real users and root will be
in the pulse-access group by default, it wont add much in the way of
security.

Bill

On Wed, Feb 10, 2010 at 5:30 PM, Lennart Poettering
 wrote:
> On Sun, 07.02.10 22:54, Bill Cox (waywardg...@gmail.com) wrote:
>
>> Finally, disable group-based authentication to use the sound system.
>> Edit /etc/pulse/system.pa.  Find the line that reads:
>>     load-module module-native-protocol-unix
>> and change it to read:
>>   load-module module-native-protocol-unix auth-anonymous=1
>
> It's much easier and safer to simply add all users to the
> "pulse-access" group instead of doing dirty security hacks like this.
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Maarten Bosmans]

2010/2/11 Lennart Poettering :
> On Wed, 10.02.10 10:45, Maarten Bosmans (mkbosm...@gmail.com) wrote:
>
>> The other mode is the system-wide daemon mode. This follows more the
>> traditional unix model of a dedicated pulse user running a daemon to
>> which other users can connect. The system mode is more applicable to
>> an audio server/appliance scenario.
>
> I would actually argue that the normal per-session PA logic is much
> more unixish than anything else. At least on my classic TTYs the bell
> sound was actually generated in the terminal computer and not on the
> server computer. And on the old standalone X terminals, it's the very
> same thing. XBell() is called on the terminal server, and the X terminal
> generates the sound.

That makes sense for the bell.

I was referring to the daemon though. In my view the system wide
daemon running as a dedicated user (apache, postgres) is an example of
the traditional unix model and the per-user daemon (dbus, pulse) is
another approach that is gaining a lot of popularity lately on linux
distributions.

Maarten

> So, what was true for teletype and X terminals back in the 80s, where
> the beep sound was played by an app on the terminal server and
> generated on the terminal client, is still true in the PA world: the
> audio stream a music player app plays on the terminal server is played
> back on the terminal client.
>
> So, once and for all, if someone complains that PA wasn't unixish
> enough: first of all, I don't care, and secondly that's a completely
> bogus statement and is not true.
>
> Lennart
>
> --
> Lennart Poettering                        Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/           GnuPG 0x1A015CC4
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Thu, 11.02.10 02:01, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble:
> > A question about the console-kit approach, where the user physically
> > near the sound hardware is the person that gets to use it...
> > 
> > A favorite trick of mine is to ssh into a machine, and use the sound
> > hardware there to announce some kind of event. It might be an alarm to
> > wake up a family member, or a remotely-generated event alert. It might
> > not be SSH, it might be a cron job, or a CGI...
> > 
> > Assuming I'm the administrator of the machine, how can I pull off this
> > trick in the context of console-kit? If it's even possible, it sounds
> > like I'd have to suspend the existing pulseaudio connection by assigning
> > rights to a "virtual console" of some kind, which would then have the
> > opportunity to use the audio device until it released it.
> 
> If you're an admin you'd simply "su" to the active user and use their
> access credentials to access their PA system.

Also, one could make your admin user member of the "audio" group, and
access the audio device regardless of who's logged in -- but potentially
you'll clash with a running PA/audio app which already has the device open.

Or, at a higher level you could configure /etc/pulse/default.pa's
module-native-protocol-unix to use an "auth-group" even when running
in per-session-mode. All user session should then pick that up and
members of that group will always be allowed access.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Thu, Feb 11, 2010 at 1:00 AM, Lennart Poettering
 wrote:
> On Mon, 08.02.10 19:11, olin.pulse@shivers.mail0.org 
> (olin.pulse@shivers.mail0.org) wrote:
>
>> PA is a system that manages access to a hardware resource, in a network
>> distributed context. Such a system must have mechanism for managing
>> authentication and privileges -- one that works in a network distributed
>> context.
>>
>> X11 is in a very similar position -- except that there's less call for shared
>> access to the resources it manages (in the sense that, with X11, multiple
>> humans usually don't want access to the same screen, keyboard or mouse at the
>> same time). X uses ~/.Xauthority, but, these days, it mostly "lifts" this
>> base mechanism up to a distributed setting by means of ssh.
>>
>> OK, so that's X11. I cannot figure out what PA's mechanism for this
>> is.
>
> By default we store the access creds of the PA server in the root
> window of the X server. Which means that everyone who has access to
> the X server has access to the matching PA server, too. So we mostly
> follow the X logic, with one exception: we only have one PA instance
> running per user and machine, and share it between all sessions of the
> same user, so that every session of the same user has access to all
> local cards that belong to any of the X screens.
>
>> I sort of get the sense, from this per-user-login server model that
>> PA has the horrible one-persone/one-computer model of "the person at
>> the console is the person using the computer," which was inflicted
>> on the world by Microsoft Windows. If so, this is a real design
>> error, one that doesn't sync up with Unix, which has always had a
>> multi-user model of the world.
>
> Right. "horrible".
>
> I mean, what you say is utterly bogus, but I don't even want to dicuss
> that here. I'd just like to refer you to the CK work that has been
> done, because that is where this logic stems from. The logic is
> certainly nothing we PA folks came up with. It's something CK was
> designed for. So please complain not to me. I certainly believe CK is
> what we want, but I am not its maintainer.

it does not mean that CK is the absolute right solution for everyone I
second that
the current default setup is not good for many users.
It does not help to force people to a logic which they do not accept.
I know that you
see many things to be broken but many people lived with it very good
for more than at
least 10 years, until you came up with the first unstable PA hacks
which you tried to fix it over
the years (good attitude).

I do agree with the other users, I do see that there is a scenario
where your design is okay but
it's not the ultimate solution for it, you can work as hard as you can
to convince people but it
will not work out.

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Jeremy Nickurak at 11/02/10 01:48 did gyre and gimble:
> A question about the console-kit approach, where the user physically
> near the sound hardware is the person that gets to use it...
> 
> A favorite trick of mine is to ssh into a machine, and use the sound
> hardware there to announce some kind of event. It might be an alarm to
> wake up a family member, or a remotely-generated event alert. It might
> not be SSH, it might be a cron job, or a CGI...
> 
> Assuming I'm the administrator of the machine, how can I pull off this
> trick in the context of console-kit? If it's even possible, it sounds
> like I'd have to suspend the existing pulseaudio connection by assigning
> rights to a "virtual console" of some kind, which would then have the
> opportunity to use the audio device until it released it.

If you're an admin you'd simply "su" to the active user and use their
access credentials to access their PA system.

> Incidentally, this seems to be the same use case that vision-impaired
> users were dealing with recently: How can system-level processes inject
> their inputs to the speakers without a system-level pulseaudio daemon
> sharing that hardware?

They can't and they shouldn't. The problem is that the models are
broken. All the models for this have been decided upon and it's just
waiting for people to do the implementation in the various bits of the
stack.

See the archives for more info.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Jeremy Nickurak]

A question about the console-kit approach, where the user physically near
the sound hardware is the person that gets to use it...

A favorite trick of mine is to ssh into a machine, and use the sound
hardware there to announce some kind of event. It might be an alarm to wake
up a family member, or a remotely-generated event alert. It might not be
SSH, it might be a cron job, or a CGI...

Assuming I'm the administrator of the machine, how can I pull off this trick
in the context of console-kit? If it's even possible, it sounds like I'd
have to suspend the existing pulseaudio connection by assigning rights to a
"virtual console" of some kind, which would then have the opportunity to use
the audio device until it released it.

Incidentally, this seems to be the same use case that vision-impaired users
were dealing with recently: How can system-level processes inject their
inputs to the speakers without a system-level pulseaudio daemon sharing that
hardware?

-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Jeremy Nickurak]

A question about the console-kit approach, where the user physically near
the sound hardware is the person that gets to use it...

A favorite trick of mine is to ssh into a machine, and use the sound
hardware there to announce some kind of event. It might be an alarm to wake
up a family member, or a remotely-generated event alert. It might not be
SSH, it might be a cron job, or a CGI...

Assuming I'm the administrator of the machine, how can I pull off this trick
in the context of console-kit? If it's even possible, it sounds like I'd
have to suspend the existing pulseaudio connection by assigning rights to a
"virtual console" of some kind, which would then have the opportunity to use
the audio device until it released it.

Incidentally, this seems to be the same use case that vision-impaired users
were dealing with recently: How can system-level processes inject their
inputs to the speakers without a system-level pulseaudio daemon sharing that
hardware?

-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Kevin Fox]

On Wed, 2010-02-10 at 16:52 -0800, Lennart Poettering wrote:
> On Wed, 10.02.10 16:45, Andrew McNabb (amcn...@mcnabbs.org) wrote:
> 
> > Detachable ears are called headphones. :)
> > 
> > I'm not arguing that it's practical to do, but an ideal multiseat system
> > would be able to give each user two dedicated channels, so they can each
> > plug in their own set of headphones (modern surround sound cards have
> > tons of audio outputs).  Of course, implementing and configuring this
> > would probably be extremely difficult, so I'm not volunteering. :)
> 
> You would call that "ideal"? Strange definition of ideal.


> It's
> certainly much easiert to just buy seperate super-cheap stereo USB
> sound cards for each user. 

That, greatly depends on what your companies procurement process looks
like. ;)

Kevin

> 
> Lennart
> 


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 23:22, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Lennart Poettering at 10/02/10 22:36 did gyre and gimble:
> > On Tue, 09.02.10 09:43, Markus Rechberger (mrechber...@gmail.com) wrote:
> > 
> >>> Indeed. PA is principally meant to be run per-user. Each user logged in
> >>> will have their own PA process running and each will monitor a system
> >>> service called "ConsoleKit" which tracks which user is active. We adhere
> >>> to whatever ConsoleKit tells us with regards to which user is currently
> >>> "active" (see ck-list-sessions) and only the active user has access to
> >>> the sound hardware.
> >>>
> >>> Think about how switching users works (on Linux and on Windows/OSX).
> >>> Only the user whose desktop is currently presented will be allowed to
> >>> use sound, the other user's sound is "corked" until they become active
> >>> again.
> >>
> >>
> >> Bad example as usual, on OSX everyone (who's permitted to use the
> >> audio unit) can just log in and use the audio unit.
> > 
> > Do we need to have this pointless discussion every second months? 
> > 
> > Last time I checked OSX audio of the sessions that are not in the
> > foreground is paused, and only one session has access to the sound
> > cards at a time. Exactly like on PA, or on Windows.
> 
> This is correct. There is one difference tho' on OSX (which is IMO
> horrible) and that is the fact that an inactive user can ssh in and play
> sound (via e.g. afplay command line app). I annoyed the hell out of
> someone in my office today by doing just this.
> 
> But from a user-facing perspective - e.g. logged in user they using fast
> user switching - it behaves exactly as you described.
> 
> What I didn't try was issuing a "sleep 10s; afplay foo.mp3" and
> initiating the switch. I'll try that tomorrow.

So you can even monitor everything he says via the mike? If so, could
you please provide a live stream on the internet please? ;-)

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Thu, 11.02.10 00:44, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> > If people want to allow users unconditional access to audio devices,
> > regardless whether they are logged in on the console, then they can
> > add them to that group. That's fine. ACL certainly are more flexible,
> > but just adding someone to the "audio" group is certainly simpler.
> > 
> > Most distros support both CK/ACL-based access and audio group based
> > access out-of-the-box. And that's fine that way and not going to go
> > away.
> 
> But if a good proportion of the audio hardware out there does not
> support hardware mixing, should this mode of operation be encouraged?
> 
> I'd have thought that by enabling this way of working it's just
> ultimately going to lead to problems when such hardware is attempted to
> be accessed concurrently?

The "audio" group is certainly no fix for apps fighting for exclusive
device access. Note that by default that group is empty, so this
feature is unused by default. However we want to make things easy for
the cases where access control is not exclusively bound to the active
session. And it might even make sense for headless systems, or if PA
isn't used.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 16:45, Andrew McNabb (amcn...@mcnabbs.org) wrote:

> Detachable ears are called headphones. :)
> 
> I'm not arguing that it's practical to do, but an ideal multiseat system
> would be able to give each user two dedicated channels, so they can each
> plug in their own set of headphones (modern surround sound cards have
> tons of audio outputs).  Of course, implementing and configuring this
> would probably be extremely difficult, so I'm not volunteering. :)

You would call that "ideal"? Strange definition of ideal. It's
certainly much easiert to just buy seperate super-cheap stereo USB
sound cards for each user. 

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Ng Oon-Ee]

On Thu, 2010-02-11 at 01:46 +0100, Lennart Poettering wrote:
> On Tue, 09.02.10 21:57, Michał Sawicz (mic...@sawicz.net) wrote:
> 
> > 4. there's a dialog on the active user's session with 'User  tries
> > to access your audio equipment with application , allow / deny?'
> 
> For every event sound? Really?
> 
> Lennart
> 
I believe what was being referred to is a permissions-based system. Sort
of like on windows, the "Do you want to allow machine OMGCOOLPICS to
have access to your C:\ drive?" after which it saves your answer for
future sounds/streams.

You've already covered previously why this sort of permissions aren't
PA's job though. I must say this discussion is pretty interesting, even
though the substance has been the same every few months.

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 11:16, Bill Cox (waywardg...@gmail.com) wrote:

> As for concerns about running system-wide... Ubuntu already disallows
> user loaded modules, and I'm not hearing a lot of complaints.  When

it's not Ubuntu that disallows that. It's upstream PA. 

So, this breaks bt and hotplugging and a lot of other stuff. You
really believe that people won't miss that?

I mean, maybe that fact that you hear no complaints might be due to the
fact that nobody runs system-wide mode. Every thought about that?

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 21:57, Michał Sawicz (mic...@sawicz.net) wrote:

> 4. there's a dialog on the active user's session with 'User  tries
> to access your audio equipment with application , allow / deny?'

For every event sound? Really?

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 11/02/10 00:25 did gyre and gimble:
> On Tue, 09.02.10 18:51, Colin Guthrie (gm...@colin.guthr.ie) wrote:
> 
>>> By the way normally only the users who are in the audio group are
>>> allowed to access audio (not entirely sure how this is handled with
>>> osx though), so it's not like a random user is allowed to access the
>>> audio device.
>>
>> The "audio" group is a legacy and is no longer needed. ACLs on the audio
>> device are far more flexible.
> 
> It's actually not legacy. In fact it was known on Debian for a long
> time and only recently added to the other distros, too, pushed in via
> udev.

Ahh fair enough. Thanks for enlightening me (as usual!)

> If people want to allow users unconditional access to audio devices,
> regardless whether they are logged in on the console, then they can
> add them to that group. That's fine. ACL certainly are more flexible,
> but just adding someone to the "audio" group is certainly simpler.
> 
> Most distros support both CK/ACL-based access and audio group based
> access out-of-the-box. And that's fine that way and not going to go
> away.

But if a good proportion of the audio hardware out there does not
support hardware mixing, should this mode of operation be encouraged?

I'd have thought that by enabling this way of working it's just
ultimately going to lead to problems when such hardware is attempted to
be accessed concurrently?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 20:07, Markus Rechberger (mrechber...@gmail.com) wrote:

> > Bypassing this layer and accessing things directly is not IMO a good
> > design. Everything is possible with the appropriate mechanisms in place
> > and no functionality is sacrificed, but you have to be prepared to
> > accept that old approaches will not last forever nor survive the tests
> > of time.
> 
> your scenario is definitely over engineered for many people out
> there.  I see your points and I see it as a valid scenario but as
> mentioned not as a valid reason for hard restricting users. On the
> other side the only way out of this dilemma is to set up systemwide
> service which pretty much cannot be done in a generic way with all
> distributions which use PA due random config paths and inherited
> configuration files.  As long as this isn't fixed I hope operating
> systems don't make a hard dependency on PA only so people can still
> jump back to the old behavior.

It's not particularly hard to load another module-native-protocol-unix
instance and losen its access restrictions to allow other users
access, if you don't care about security.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 18:51, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> > By the way normally only the users who are in the audio group are
> > allowed to access audio (not entirely sure how this is handled with
> > osx though), so it's not like a random user is allowed to access the
> > audio device.
> 
> The "audio" group is a legacy and is no longer needed. ACLs on the audio
> device are far more flexible.

It's actually not legacy. In fact it was known on Debian for a long
time and only recently added to the other distros, too, pushed in via
udev.

If people want to allow users unconditional access to audio devices,
regardless whether they are logged in on the console, then they can
add them to that group. That's fine. ACL certainly are more flexible,
but just adding someone to the "audio" group is certainly simpler.

Most distros support both CK/ACL-based access and audio group based
access out-of-the-box. And that's fine that way and not going to go
away.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Michał Sawicz]

Dnia 2010-02-10, śro o godzinie 16:45 -0700, Andrew McNabb pisze:
> I'm not arguing that it's practical to do, but an ideal multiseat
> system
> would be able to give each user two dedicated channels, so they can
> each
> plug in their own set of headphones (modern surround sound cards have
> tons of audio outputs).  Of course, implementing and configuring this
> would probably be extremely difficult, so I'm not volunteering. :)

Well, IIUC that's exactly what PA does - multi-seat does not mean two
seats and one screen/keyboard/mouse/speakers - it means this set for
every user in every seat. And that's what PA does.

-- 
Pozdrawiam
Michał (Saviq) Sawicz


signature.asc
Description: To jest część  wiadomości podpisana cyfrowo
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Andrew McNabb]

On Thu, Feb 11, 2010 at 12:16:44AM +0100, Lennart Poettering wrote:
> 
> This is nonsense. I am not sure how your ears are constructed, but on
> a multiseat system if you want to share a soundcard between two seats,
> where would you put the speakers so that the two users have the same
> distance from L and R and they are on the left and the right side? I
> mean, those users would have to sit on top of each other or detachable
> ears or something.

Detachable ears are called headphones. :)

I'm not arguing that it's practical to do, but an ideal multiseat system
would be able to give each user two dedicated channels, so they can each
plug in their own set of headphones (modern surround sound cards have
tons of audio outputs).  Of course, implementing and configuring this
would probably be extremely difficult, so I'm not volunteering. :)


-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 10:45, Maarten Bosmans (mkbosm...@gmail.com) wrote:

> The other mode is the system-wide daemon mode. This follows more the
> traditional unix model of a dedicated pulse user running a daemon to
> which other users can connect. The system mode is more applicable to
> an audio server/appliance scenario.

I would actually argue that the normal per-session PA logic is much
more unixish than anything else. At least on my classic TTYs the bell
sound was actually generated in the terminal computer and not on the
server computer. And on the old standalone X terminals, it's the very
same thing. XBell() is called on the terminal server, and the X terminal
generates the sound.

So, what was true for teletype and X terminals back in the 80s, where
the beep sound was played by an app on the terminal server and
generated on the terminal client, is still true in the PA world: the
audio stream a music player app plays on the terminal server is played
back on the terminal client.

So, once and for all, if someone complains that PA wasn't unixish
enough: first of all, I don't care, and secondly that's a completely
bogus statement and is not true.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Mon, 08.02.10 19:11, olin.pulse@shivers.mail0.org 
(olin.pulse@shivers.mail0.org) wrote:

> PA is a system that manages access to a hardware resource, in a network
> distributed context. Such a system must have mechanism for managing
> authentication and privileges -- one that works in a network distributed
> context.
> 
> X11 is in a very similar position -- except that there's less call for shared
> access to the resources it manages (in the sense that, with X11, multiple
> humans usually don't want access to the same screen, keyboard or mouse at the
> same time). X uses ~/.Xauthority, but, these days, it mostly "lifts" this
> base mechanism up to a distributed setting by means of ssh.
> 
> OK, so that's X11. I cannot figure out what PA's mechanism for this
> is. 

By default we store the access creds of the PA server in the root
window of the X server. Which means that everyone who has access to
the X server has access to the matching PA server, too. So we mostly
follow the X logic, with one exception: we only have one PA instance
running per user and machine, and share it between all sessions of the
same user, so that every session of the same user has access to all
local cards that belong to any of the X screens.

> I sort of get the sense, from this per-user-login server model that
> PA has the horrible one-persone/one-computer model of "the person at
> the console is the person using the computer," which was inflicted
> on the world by Microsoft Windows. If so, this is a real design
> error, one that doesn't sync up with Unix, which has always had a
> multi-user model of the world.

Right. "horrible". 

I mean, what you say is utterly bogus, but I don't even want to dicuss
that here. I'd just like to refer you to the CK work that has been
done, because that is where this logic stems from. The logic is
certainly nothing we PA folks came up with. It's something CK was
designed for. So please complain not to me. I certainly believe CK is
what we want, but I am not its maintainer.

Also, last time I checked Unix was a pretty broken system. Might be
better than many, but Unix is certainly not user friendly, and a
system from the 70s. We try to build a modern OS here, and that means
we use what is good and innovate where it isn't. That's why people
have come up with CK and it got adopted by the various distributions.

If you believe that traditional Unix is the holy grail, then maybe
modern Linux systems are not the right choice for you. If you however
are interested in a modern multi-user/multi-seat system which inherits
the good stuff from Unix, then you're welcome.

> Maybe I'm wrong. I can't figure out *what* the model is, really. When I click
> on padevchooser's "Configure Local Sound Server" entry, I get a window whose
> "Network Server" tab lets me "enable network access to local sound devices."
> Furthermore, I can set or clear a checkbox for "Don't require authentication."
> But I can find nowhere any description of what this authentication would be.
> The documentation for PulseAudio is pretty weak; it mostly says that "things
> work; just try them out." That's not documentation.

Checked the FAQ?

Sure, the PA docs are not perfect and not complete, but they are
certainly better than for many projects and you are always welcome to
contribute here.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 14:51, Bill Cox (waywardg...@gmail.com) wrote:

> The power savings on a laptop will be so close to zero, you couldn't
> measure the improvement in battery life.  40 interupts per second
> (what raw ALSA does) compared to streaming 22KB per seccond to the
> sound card is too small to care.  You wont notice any improvement.

Man, please make sure to inform Intel about that, so that they stop
designing their systems for this logic. And Microsoft and Apple too,
so that they can drop the whole logic again from Windows and MacOS. 

I mean, how dumb from them, that they couldn't see what is so obvious
to you!

It's not that we came up with the tsched idea. Didn't you know? In Free
Software we don't innovate, we just reimplement other people's ideas,
but better.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 11:32, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> One is the fact that why should a module be loaded into a system-wide
> component for a specific user? e.g. user A pairs his bluetooth headset
> which will require that the bluetooth sink becomes available - this
> should only be for user A, no other users, but user A is somehow allowed
> to load a module into the system service for this to happen. Users
> loading modules into a system service is generally a security concern
> (which is my most system wide daemons disallow module loading).

Also note that the auth credentials (i.e. PINs) for the bt stuff would
have to be passed to the server, but should be kept private for the
user.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 05:50, Bill Cox (waywardg...@gmail.com) wrote:

> 
> Here's what I don't understand.  Why doesn't PA run in system-wide
> mode, but still do all the same user-permission checks it does now,
> and only authorize the current user to access the sound card? 

Because that is extraordinarily difficult to get right. first of all,
we would have to authorize every single request, and come up with ACL
logic for every single entity inside of PA. i.e. if a user issues
"move" request we would have to check whether the user is allowed to
move this particular stream and to this particular device and so
on. This would add a substantial and complex codebase to PA. Also,
suddenly the bigger part of PA suddenly becomes security sensitive
because we can never trust the user anymore.

This would also mean that we would have to get rid of stuff like SHM
data transfer because I simply see no way to implement this on current
linuxes in a safe way so that the two sides don't have to trust each
other. (the most trivial access is that one side ftruncates its shm
region triggering a SIGBUS in the other on the next access. And
catching those SIGBUS and handling it sanely and securely you cannot
really do. but that's just the beginning, it goes downhill from
there.)

I mean, you are welcome to write such a franken-sound-server, which
can deal with all of this. But I simply don't think it is feasible. I
won't wast my time on that and reimplement big parts of the linux
kernel in userspace. 

Certainly not just because some people want to playback audio
simultaneously from multiple users and cannot configure
module-native-protocol-xxx/module-tunnel-sink for that.

> Is there any advantage in running the whole PA daemon in user
> space?  Why have multiple PA processes running when there are
> multiple users?  Doesn't this waste memory?

Next question: why have multiple firefox processes running? doesn't
that waste memory? I mean, multiple users could share one
instance, right? 

> If PA were run this way, it would be trivial to allow specific root
> processes or authorized users to access the sound card at the same
> time as the current user.

"trivial". Right.

> Also, why does zero latency by default increase CPU power?  SFAIK,
> zero latency (or inperceptably small) is the default in all other
> sound systems, and I haven't heard of increased CPU usage as a
> result.

"zero latency" does not literally mean what you apparently think it
does. It simply means that you can override the very sample that is
currently passed to the DAC, it does not mean you really get 0 latency
when streaming a continuous stream.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 09:59, Markus Rechberger (mrechber...@gmail.com) wrote:

> this is another wrong assumption, libusb uses raw USB access, if every
> user would have access
> to USB some devices might be damaged.
> Sane would need to be serverbased, full raw access to the usb bus
> would seriously be a security
> risk (imagine RAW USB access to a USB harddisk).

This is nonsense. Since ages we by default add ACLs for the console
user for libusb devices for cameras, scanners, and so on. That too
works via udev-acl.

You are spreading FUD and lies. You are annoying. And are stealing my
time. I'd prefer if you'd waste other people's time, and stop lighting
up the flames of this flamewar over and over again.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 10/02/10 22:36 did gyre and gimble:
> On Tue, 09.02.10 09:43, Markus Rechberger (mrechber...@gmail.com) wrote:
> 
>>> Indeed. PA is principally meant to be run per-user. Each user logged in
>>> will have their own PA process running and each will monitor a system
>>> service called "ConsoleKit" which tracks which user is active. We adhere
>>> to whatever ConsoleKit tells us with regards to which user is currently
>>> "active" (see ck-list-sessions) and only the active user has access to
>>> the sound hardware.
>>>
>>> Think about how switching users works (on Linux and on Windows/OSX).
>>> Only the user whose desktop is currently presented will be allowed to
>>> use sound, the other user's sound is "corked" until they become active
>>> again.
>>
>>
>> Bad example as usual, on OSX everyone (who's permitted to use the
>> audio unit) can just log in and use the audio unit.
> 
> Do we need to have this pointless discussion every second months? 
> 
> Last time I checked OSX audio of the sessions that are not in the
> foreground is paused, and only one session has access to the sound
> cards at a time. Exactly like on PA, or on Windows.

This is correct. There is one difference tho' on OSX (which is IMO
horrible) and that is the fact that an inactive user can ssh in and play
sound (via e.g. afplay command line app). I annoyed the hell out of
someone in my office today by doing just this.

But from a user-facing perspective - e.g. logged in user they using fast
user switching - it behaves exactly as you described.

What I didn't try was issuing a "sleep 10s; afplay foo.mp3" and
initiating the switch. I'll try that tomorrow.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 08:54, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Yeah, if we have permission on the device, we use it, otherwise it's
> ignored. When users are switched away, CK fires off dbus signals and we
> recheck our device access etc. We don't accept any input from alsa when
> we do not have permission on the device (even tho' we can read mixer
> settings). If we were able to access the device when we were started but
> subsequently have our permission removed, this is indicative of "user
> switching" (i.e. "Show Login Window" or "Switch User" or "Log in as a
> Different User") in which case we cork any streams tied to those devices
> we can no longer access until such times as they become available to us
> again.

Small correction: for device access PA does not intrefac with
udev or CK. We simply use access() on the device nodes and subscribe
to changes with inotify.

That means that if folks patch their access modes of the device nodes
we will handle accordingly. It's the most robust solution I believe.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Wed, 10.02.10 07:14, David Henningsson (launchpad@epost.diwic.se) wrote:

> But printers are more of a system-wide resource, and for some use cases,
> so is the soundcard. 

This is nonsense. I am not sure how your ears are constructed, but on
a multiseat system if you want to share a soundcard between two seats,
where would you put the speakers so that the two users have the same
distance from L and R and they are on the left and the right side? I
mean, those users would have to sit on top of each other or detachable
ears or something.

We discussed this with a couple of folks long time ago, and decided
that some reasources are per-seat resources, and should be configured
like that. Those devices are keyboards, mice, screens, sound cards,
webcams and a couple of others. the UDEV_ACL=1 property in the udev
tree marks most of them. This discussion was mostly done on the udev
level btw, it is only indirectly related to PA.

Now, in some non-standard cases it might make sense to have the access
rules deviate from this default, but those are the exceptions, not the
common cases. And that means that you configure it that way, but the
default will be the safe, common case, not the dangerous uncommon
case.

So, how do you reconfigure access to audio devices like that? More
recent udev versions know an "audio" group. Just make yourself a
member of that, and you'll have access regardless of the current
console user. Or alternatively use some udev rules to patch the
device access differently.

BTW, I really do not know why I am even responding, this has been
answered before and before. Do you know this Google thing? It's kinda
cool, you should try it.

> And then, sharing makes sense. If another user is
> allowed to print a document while I'm logged in, why shouldn't he be
> able to play a sound? So would then the solution be to run PA as a
> system-wide daemon, and possibly assign soundcards to it via udev?

Right, allow every user to listen into all voip calls, and to fake
output. Lemme guess, you disable access control to your X11 screen too?

> And the way ck/udev tells PA what devices it can use, is through device
> permissions?

PA gets the device access rights directly from the /dev tree. It
doesn't query CK or udev for those. We try to keep our stacks thin.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 17:59, Markus Rechberger (mrechber...@gmail.com) wrote:

> 
> On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox  wrote:
> > The corking stuff in PA is very cool.  I don't think anyone objects to
> > it.  But couldn't we quell all the "PA stinks!" posts by just allowing
> > some processes/groups/users to have constant access to audio?
> >
> > Comparisons to MAC and Windows have been going on for a while, and the
> > PA guys are basically right that PA is more like Windows and Mac than
> > the older sound systems.  If I'm not mistaken, the real issue is all
> > the very valid reasons people out in Linux land have for multi-user
> > simultaneous access to sound.  I'd say those guys are generating most
> > of the negative PA e-mails I read, and not just on this forum.
> >
> 
> you cannot compare it with mac, on mac multiuser access works like it
> worked with alsa and OSS.

Uh. This is very a confused statement.

PA opens the device when the ALSA device node access permissions allow
that. That access is controlled via udev's acl tool. We open the
device when we get access to the device nodes, and we close it when we
lose it.

The legacy OSS device node permissions follow exactly the ALSA device
node permissions.

Which basically means that we simply follow the ALSA/OSS permission
logic. We don't open any new doors, we don't close any from the
underlying system.

As such the destinction between ALSA/OSS and PA regardings access control
is simple not existant, your claim above is bogus.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 22:52, David Henningsson (launchpad@epost.diwic.se) wrote:

> Colin Guthrie wrote:
> > 'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble:
> > This whole thing has been discussed to death, and I really don't feel
> > like being drawn into the whole thing again.
> 
> >From what I've read here, I'm afraid it's going to keep coming up until
> we solve it somehow.

I can live with that. Asking them to try the mailing list archives or
google is not a particularly difficult task.

> There are just too many people for where the ordinary PA setup (all
> soundcards are of exclusive use to the person logged into the current X
> session) is not acceptable, and worse, it isn't easy for them to either
> reconfigure PA, or replace PA, with something that suits their
> needs.

I doubt the "too many". The handful of people coming up with this
from time to time is fairly minimal, I you allow me to say so.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 18:41, Tanu Kaskinen (ta...@iki.fi) wrote:

> ti, 2010-02-09 kello 11:17 -0500, Bill Cox kirjoitti:
> > The corking stuff in PA is very cool.  I don't think anyone objects to
> > it.  But couldn't we quell all the "PA stinks!" posts by just allowing
> > some processes/groups/users to have constant access to audio?
> 
> That's easier said than done. Only one process can have direct access to
> the sound card at a time. Each user has his own pulseaudio instance
> running. How do you implement constant access in such scenario? I fear
> it would require a major redesign effort in pulseaudio. I haven't seen
> any concrete design proposals enabling simultaneous access for multiple
> users while at the same time retaining all the desirable properties that
> the current system has.

Also, if this is all just about ways so that different users can pass
audio to each other, there are simpler ways to achieve that.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 12:24, Jeremy Nickurak (jer...@nickurak.ca) wrote:

> On Tue, Feb 9, 2010 at 09:41, Tanu Kaskinen  wrote:
> 
> > That's easier said than done. Only one process can have direct access to
> > the sound card at a time. Each user has his own pulseaudio instance
> > running. How do you implement constant access in such scenario? I fear
> > it would require a major redesign effort in pulseaudio. I haven't seen
> > any concrete design proposals enabling simultaneous access for multiple
> > users while at the same time retaining all the desirable properties that
> > the current system has.
> 
> 
> Off the top of my head
> 
> "root" or other system-level pulseaudio instance opens and owns the physical
> hardware for the entire time a computer is up.
> 
> All the user pulseaudio instances connect through that.
> 
> What's the downside here?

You don't want to stack audio stacks (hey, a pun!), for latency,
memory consumption reasons.

Also, you don't want to get into this permission mess, which you will
doubtlessly enter if you want to make this fast, i.e. continue to
support SHM and so on.

> Alternatively, rely on the underlying layer to do multiplexing. If the
> hardware supports it, awesome. If it doesn't, let dmix handle it.

Modern hw doesn't support it. And dmix doesn't do any of the
timer-based scheduling stuff we want.

It's not that easy.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 11:17, Bill Cox (waywardg...@gmail.com) wrote:

> The corking stuff in PA is very cool.  I don't think anyone objects to
> it.  But couldn't we quell all the "PA stinks!" posts by just allowing
> some processes/groups/users to have constant access to audio?

Tsss. This is a pretty peripheral battle field. I am quite sure that
the this will not make the complainers shut up.

> I guess the only other really nasty e-mails I read about PA are due to
> old unmaintained code (typically games) that have too much delay in
> PA.  Is there any good reason that the default latency in PA for
> programs that don't bother setting a desired latency is greater than
> zero?

I think this is really not how things are. At least not from my
perspective, which I think it a very informed one how I like to think.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 09:27, Bill Cox (waywardg...@gmail.com) wrote:


> I think this is one area where PulseAudio could be improved, though I
> can't quite figure out how!  Surely, there must be some way to allow
> specific processes or users to have full sound access, while otherwise
> sticking to the one-user-at-a-time model.

You know, this has been discussed to death. Try the mailing list
archives, try google. No need to discuss this again every second month.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 09:43, Markus Rechberger (mrechber...@gmail.com) wrote:

> > Indeed. PA is principally meant to be run per-user. Each user logged in
> > will have their own PA process running and each will monitor a system
> > service called "ConsoleKit" which tracks which user is active. We adhere
> > to whatever ConsoleKit tells us with regards to which user is currently
> > "active" (see ck-list-sessions) and only the active user has access to
> > the sound hardware.
> >
> > Think about how switching users works (on Linux and on Windows/OSX).
> > Only the user whose desktop is currently presented will be allowed to
> > use sound, the other user's sound is "corked" until they become active
> > again.
> 
> 
> Bad example as usual, on OSX everyone (who's permitted to use the
> audio unit) can just log in and use the audio unit.

Do we need to have this pointless discussion every second months? 

Last time I checked OSX audio of the sessions that are not in the
foreground is paused, and only one session has access to the sound
cards at a time. Exactly like on PA, or on Windows.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Mon, 08.02.10 21:01, olin.pulse@shivers.mail0.org 
(olin.pulse@shivers.mail0.org) wrote:

> 
> Bill Cox:
> > While the "right" way is not system-wide mode, in practice, I find
> > system-wide mode to be very stable and usable on Ubuntu systems that
> > have multiple users trying to send sound to the speakers. 
> 
> So, I'm still wondering: what *is* the "right way" for this use case? Is it
> the case that PulseAudio just doesn't address it?

On a headless system, or on a system where no local users exist
(i.e. thin clients), use the system-wide mode. On multi-user systems,
don't.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Tue, 09.02.10 03:16, Markus Rechberger (mrechber...@gmail.com) wrote:

> 
> On Tue, Feb 9, 2010 at 3:01 AM,   wrote:
> > Bill Cox:
> >> While the "right" way is not system-wide mode, in practice, I find
> >> system-wide mode to be very stable and usable on Ubuntu systems that
> >> have multiple users trying to send sound to the speakers.
> >
> > So, I'm still wondering: what *is* the "right way" for this use case? Is it
> > the case that PulseAudio just doesn't address it?
> 
> There is no right way pulseaudio was not designed to support multiple
> users at the same time (without the depreciated exception of running
> it as system wide daemon).

Not true.

Firstly, what we don't support is simultaneous playback on the same
device by multiple different users, unless you reconfigure
things. Which is the same as for traditional alsa dmix.

Secondly, the system wide mode is not deprecated. It's just not
recommended for use for multi-user systems. It's fine on headless
devices, or on thin clients, where no local user exists.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Lennart Poettering]

On Sun, 07.02.10 22:54, Bill Cox (waywardg...@gmail.com) wrote:

> Finally, disable group-based authentication to use the sound system.
> Edit /etc/pulse/system.pa.  Find the line that reads:
> load-module module-native-protocol-unix
> and change it to read:
>   load-module module-native-protocol-unix auth-anonymous=1

It's much easier and safer to simply add all users to the
"pulse-access" group instead of doing dirty security hacks like this.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

The power savings on a laptop will be so close to zero, you couldn't
measure the improvement in battery life.  40 interupts per second
(what raw ALSA does) compared to streaming 22KB per seccond to the
sound card is too small to care.  You wont notice any improvement.

On Wed, Feb 10, 2010 at 2:26 PM, Colin Guthrie  wrote:
> 'Twas brillig, and Arun Raghavan at 10/02/10 19:26 did gyre and gimble:
>> On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote:
>>> Ok, the new "glitchless" code sounds cool.  Reducing the interrupts
>>> seems close to pointless from a power savings view, unless we're in an
>>> embedded environment where we slow down the CPU and lower it's power
>>> on sub-second intervals.  Otherwise, copying the data the data to the
>>> sound buffer will heavily dominate power.
>>
>> Why would the power concerns not apply on laptops and netbooks?
>
> And tablets *everyone* loves tablets these days except for all
> those folks who don't :p
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mandriva.com/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Arun Raghavan at 10/02/10 19:26 did gyre and gimble:
> On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote:
>> Ok, the new "glitchless" code sounds cool.  Reducing the interrupts
>> seems close to pointless from a power savings view, unless we're in an
>> embedded environment where we slow down the CPU and lower it's power
>> on sub-second intervals.  Otherwise, copying the data the data to the
>> sound buffer will heavily dominate power.
> 
> Why would the power concerns not apply on laptops and netbooks?

And tablets *everyone* loves tablets these days except for all
those folks who don't :p

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Arun Raghavan]

On Wed, 2010-02-10 at 11:16 -0500, Bill Cox wrote:
> Ok, the new "glitchless" code sounds cool.  Reducing the interrupts
> seems close to pointless from a power savings view, unless we're in an
> embedded environment where we slow down the CPU and lower it's power
> on sub-second intervals.  Otherwise, copying the data the data to the
> sound buffer will heavily dominate power.

Why would the power concerns not apply on laptops and netbooks?

-- Arun

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Maarten Bosmans]

2010/2/10 samuel :
> On Wed, 10 Feb 2010 10:45:33 +0100
> Maarten Bosmans  wrote:
>> Perhaps the confusion stems from the fact that PulseAudio has two
>> different modes. The normal per-user mode, which should almost always
>> be used, uses the model of a single user having access to the hardware
>> of a single seat. This works great and really polishes the whole
>> desktop experience, including support for fast user switching, remote
>> ssh logins, etc.
>>
>> The other mode is the system-wide daemon mode. This follows more the
>> traditional unix model of a dedicated pulse user running a daemon to
>> which other users can connect. The system mode is more applicable to
>> an audio server/appliance scenario.
>> I have, for example, PulseAudio running as a system daemon on a
>> dedicated server, connected to several speakers around the house. A
>> local MPD process on the server can play music through the pulse
>> server, or I can ssh to the box and start an internet radio stream.
>> Moreover, sound can be redirected from any desktop to the pulse
>> server, so that even the neighbors can enjoy the YouTube clips I'm
>> watching.
>>
> I have basically the same setup - would you mind sharing your config
> files with me? Preferably of both, the server, and of your "clients",
> that is e.g. the computer you watch the youtube clips on, that your
> neighbors enjoy...

The box is currently out of order, so I can't check the config files.
Following is from memory.

To run PulseAudio on the server in system mode: pulseaudio --system
As mentioned earlier, in Ubuntu you have a script in /etc/init.d for
it. Read it and set the appropriate settings. Don't forget to
configure users and groups correctly
(http://pulseaudio.org/wiki/SystemWideInstance)
Make sure module-native-protocol-tcp is loaded with authentication
settings as to let users on other computers access PulseAudio.
http://pulseaudio.org/wiki/Modules is your friend here.

On the client side you can start a program with the PULSE_SERVER
environment variable set to your server name. This redirects all
libpulse audio to your audio server.
For more control you can make tunnels, see module-tunnel-* and
module-zeroconf-*. Then you can switch streams between local playback
and on the audio server, e.g. using pavucontrol.

I hope this gives you enough information to get you in the right direction.

Maarten


>> So when talking about what model PulseAudio uses, it is good to keep
>> the distinction between per-user and system-wide mode, which have of
>> course very different models.
>>
>> Maarten
>> ___
>> pulseaudio-discuss mailing list
>> pulseaudio-discuss@mail.0pointer.de
>> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
> Thank you very much.
>
> --
> samuel
>
> < sam...@eightonions.com >
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

Ok, the new "glitchless" code sounds cool.  Reducing the interrupts
seems close to pointless from a power savings view, unless we're in an
embedded environment where we slow down the CPU and lower it's power
on sub-second intervals.  Otherwise, copying the data the data to the
sound buffer will heavily dominate power.

I like that in theory, it provides "zero latency" (quotes theirs).  In
practice, for speech-dispatcher, it's good enough.  I'll take a closer
look next time someone complains about an old game with too much
latency.

As for concerns about running system-wide... Ubuntu already disallows
user loaded modules, and I'm not hearing a lot of complaints.  When
running in system-wide mode, pretty much everyone seems happy.  The
complaints I'm hearing are the usual ones... how do I get my second
USB sound card working and such.  However, when run in user-mode, I
hear all sorts of bug complaints.  For example, speech-dispatcher
doesn't reliably go away when you log out fast enough for gdm's copy
to get access to the sound card.  The result is that today, in Ubuntu
Lucid, if you log out, gdm randomly wont let gdm's copy of Orca read
the login screen.  Users offer work-arounds like putting 'killall
speech-dispatcher' in .bash_logout.

If security issues were handled by a system-wide daemon, I suspect PA
could run more reliably.   In addition, a system-wide rights manager
could easily handle sound from root devices like speech-synthesizers,
or alarms.  A flaw that people will continue to complain about in PA
is it's inability to deal with multi-user sound.

Bill

On Wed, Feb 10, 2010 at 6:32 AM, Colin Guthrie  wrote:
> 'Twas brillig, and Bill Cox at 10/02/10 10:50 did gyre and gimble:
>> Here's what I don't understand.  Why doesn't PA run in system-wide
>> mode, but still do all the same user-permission checks it does now,
>> and only authorize the current user to access the sound card?  Is
>> there any advantage in running the whole PA daemon in user space?  Why
>> have multiple PA processes running when there are multiple users?
>> Doesn't this waste memory?
>>
>> If PA were run this way, it would be trivial to allow specific root
>> processes or authorized users to access the sound card at the same
>> time as the current user.
>
> Yes the system-wide approach works fine for this, but it still doesn't
> address several issues.
>
> One is the fact that why should a module be loaded into a system-wide
> component for a specific user? e.g. user A pairs his bluetooth headset
> which will require that the bluetooth sink becomes available - this
> should only be for user A, no other users, but user A is somehow allowed
> to load a module into the system service for this to happen. Users
> loading modules into a system service is generally a security concern
> (which is my most system wide daemons disallow module loading).
>
> Lots of things about the sound stack are per-user (e.g. my Apple
> Airtunes, my Bluetooth devices etc. etc.) and pushing these into a
> system service does not make sense.
>
> It is possible that a system wide component could drive the local
> hardware and a per-user component is able to deal with all the other
> stuff, per-user settings and devices etc. but also communicate with the
> server side componenet to deal with local physical hardware. This
> approach is much more complex and would no doubt introduce a lot of
> potential problems regarding SHM security and such like but it should
> all be possible. That said I'm not convinced there is a compelling
> enough use case to go down this route anyway as I've pointed out.
>
> Also there is always going to be the argument that X is a system device
> in one context and a per-user device in another. e.g. this apply
> airtunes is in my room so it's mine, but this one is in the kitchen so
> it's everyone's. No matter what approach you take there are always going
> to be some people who want it to work another way. We've got to
> concentrate on the majority use cases and so fare the only awkward ones
> pointed out are very niche and really are getting far too much
> discussion time already considering the overall goal.
>
>> Also, why does zero latency by default increase CPU power?  SFAIK,
>> zero latency (or inperceptably small) is the default in all other
>> sound systems, and I haven't heard of increased CPU usage as a result.
>
> http://0pointer.de/blog/projects/pulse-glitch-free.html
>
> In an ideal world you want a latency of about 2-10 seconds depending on
> context of the running application (e.g. a music player where you don't
> rewind/fast-forward too much and do not mix audio over the top too often
> should have a very high latency to allow the CPU to sleep as much as
> possible rather than wake up to service audio data.
>
> Col
>
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mand

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Bill Cox at 10/02/10 10:50 did gyre and gimble:
> Here's what I don't understand.  Why doesn't PA run in system-wide
> mode, but still do all the same user-permission checks it does now,
> and only authorize the current user to access the sound card?  Is
> there any advantage in running the whole PA daemon in user space?  Why
> have multiple PA processes running when there are multiple users?
> Doesn't this waste memory?
> 
> If PA were run this way, it would be trivial to allow specific root
> processes or authorized users to access the sound card at the same
> time as the current user.

Yes the system-wide approach works fine for this, but it still doesn't
address several issues.

One is the fact that why should a module be loaded into a system-wide
component for a specific user? e.g. user A pairs his bluetooth headset
which will require that the bluetooth sink becomes available - this
should only be for user A, no other users, but user A is somehow allowed
to load a module into the system service for this to happen. Users
loading modules into a system service is generally a security concern
(which is my most system wide daemons disallow module loading).

Lots of things about the sound stack are per-user (e.g. my Apple
Airtunes, my Bluetooth devices etc. etc.) and pushing these into a
system service does not make sense.

It is possible that a system wide component could drive the local
hardware and a per-user component is able to deal with all the other
stuff, per-user settings and devices etc. but also communicate with the
server side componenet to deal with local physical hardware. This
approach is much more complex and would no doubt introduce a lot of
potential problems regarding SHM security and such like but it should
all be possible. That said I'm not convinced there is a compelling
enough use case to go down this route anyway as I've pointed out.

Also there is always going to be the argument that X is a system device
in one context and a per-user device in another. e.g. this apply
airtunes is in my room so it's mine, but this one is in the kitchen so
it's everyone's. No matter what approach you take there are always going
to be some people who want it to work another way. We've got to
concentrate on the majority use cases and so fare the only awkward ones
pointed out are very niche and really are getting far too much
discussion time already considering the overall goal.

> Also, why does zero latency by default increase CPU power?  SFAIK,
> zero latency (or inperceptably small) is the default in all other
> sound systems, and I haven't heard of increased CPU usage as a result.

http://0pointer.de/blog/projects/pulse-glitch-free.html

In an ideal world you want a latency of about 2-10 seconds depending on
context of the running application (e.g. a music player where you don't
rewind/fast-forward too much and do not mix audio over the top too often
should have a very high latency to allow the CPU to sleep as much as
possible rather than wake up to service audio data.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

Here's what I don't understand.  Why doesn't PA run in system-wide
mode, but still do all the same user-permission checks it does now,
and only authorize the current user to access the sound card?  Is
there any advantage in running the whole PA daemon in user space?  Why
have multiple PA processes running when there are multiple users?
Doesn't this waste memory?

If PA were run this way, it would be trivial to allow specific root
processes or authorized users to access the sound card at the same
time as the current user.

Also, why does zero latency by default increase CPU power?  SFAIK,
zero latency (or inperceptably small) is the default in all other
sound systems, and I haven't heard of increased CPU usage as a result.

Thanks,
Bill

On Wed, Feb 10, 2010 at 4:13 AM, Colin Guthrie  wrote:
> 'Twas brillig, and Markus Rechberger at 10/02/10 08:59 did gyre and gimble:
>> On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie  wrote:
 Here's another analogy; what about the printer? If printers were
 considered a part of the seat, then user Bar wouldn't have more right to
 print a document either. (The corresponding spy-on-mic analogy would be
 that someone puts a document in a scanner and another user scans it...)

 But printers are more of a system-wide resource, and for some use cases,
 so is the soundcard. And then, sharing makes sense. If another user is
 allowed to print a document while I'm logged in, why shouldn't he be
 able to play a sound? So would then the solution be to run PA as a
 system-wide daemon, and possibly assign soundcards to it via udev?
>>>
>>> It's a fair enough point, but I don't think that sound and printers are
>>> so alike. Even the scanner example AFAIK would fall under the current PA
>>> setup - I believe that sane accesses them on a per-user basis with
>>> appropriate ACLs on the device..
>>>
>>> /me checks
>>>
>>> [co...@jimmy ~]$ su test
>>> Password:
>>> [t...@jimmy colin]$ scanimage -L
>>> libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied.
>>> libusb requires write access to USB device nodes.
>>>
>>
>> this is another wrong assumption, libusb uses raw USB access, if every
>> user would have access
>> to USB some devices might be damaged.
>> Sane would need to be serverbased, full raw access to the usb bus
>> would seriously be a security
>> risk (imagine RAW USB access to a USB harddisk).
>
> I fail to see where my assumption is here.
>
> Console-Kit has applied appropriate ACLs to the device node. That was my
> point and it was correct. No assumption stated nor needed as to what
> happens further down the stack.
>
> [t...@jimmy colin]$ getfacl /dev/bus/usb/005/011
> getfacl: Removing leading '/' from absolute path names
> # file: dev/bus/usb/005/011
> # owner: root
> # group: root
> user::rw-
> user:colin:rw-
> group::rw-
> mask::rw-
> other::r--
>
>
> The same is true of audio devices. What if multiple users were allowed
> direct access. Someone may design a security system with an alarm driven
> from the sound system but some other user has come in and hogged the
> device and as it does not support hardware mixing the "nuclear reactor
> meltdown in 5mins" alarm does not sound and we all die a horrible firey
> death. That's worse than a HD failure :p
>
>
> Col
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mandriva.com/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[samuel]

On Wed, 10 Feb 2010 10:45:33 +0100
Maarten Bosmans  wrote:

> 2010/2/9  :
> > Maybe I'm wrong. I can't figure out *what* the model is, really.
> > When I click on padevchooser's "Configure Local Sound Server"
> > entry, I get a window whose "Network Server" tab lets me "enable
> > network access to local sound devices." Furthermore, I can set or
> > clear a checkbox for "Don't require authentication." But I can find
> > nowhere any description of what this authentication would be. The
> > documentation for PulseAudio is pretty weak; it mostly says that
> > "things work; just try them out." That's not documentation.
> 
> Perhaps the confusion stems from the fact that PulseAudio has two
> different modes. The normal per-user mode, which should almost always
> be used, uses the model of a single user having access to the hardware
> of a single seat. This works great and really polishes the whole
> desktop experience, including support for fast user switching, remote
> ssh logins, etc.
> 
> The other mode is the system-wide daemon mode. This follows more the
> traditional unix model of a dedicated pulse user running a daemon to
> which other users can connect. The system mode is more applicable to
> an audio server/appliance scenario.
> I have, for example, PulseAudio running as a system daemon on a
> dedicated server, connected to several speakers around the house. A
> local MPD process on the server can play music through the pulse
> server, or I can ssh to the box and start an internet radio stream.
> Moreover, sound can be redirected from any desktop to the pulse
> server, so that even the neighbors can enjoy the YouTube clips I'm
> watching.
> 
I have basically the same setup - would you mind sharing your config
files with me? Preferably of both, the server, and of your "clients",
that is e.g. the computer you watch the youtube clips on, that your
neighbors enjoy...

> So when talking about what model PulseAudio uses, it is good to keep
> the distinction between per-user and system-wide mode, which have of
> course very different models.
> 
> Maarten
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Thank you very much.

-- 
samuel

< sam...@eightonions.com >
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Maarten Bosmans]

Bah, wrong thread

2010/2/10 Maarten Bosmans :
> 2010/2/9  :
>> Maybe I'm wrong. I can't figure out *what* the model is, really. When I click
>> on padevchooser's "Configure Local Sound Server" entry, I get a window whose
>> "Network Server" tab lets me "enable network access to local sound devices."
>> Furthermore, I can set or clear a checkbox for "Don't require 
>> authentication."
>> But I can find nowhere any description of what this authentication would be.
>> The documentation for PulseAudio is pretty weak; it mostly says that "things
>> work; just try them out." That's not documentation.
>
> Perhaps the confusion stems from the fact that PulseAudio has two
> different modes. The normal per-user mode, which should almost always
> be used, uses the model of a single user having access to the hardware
> of a single seat. This works great and really polishes the whole
> desktop experience, including support for fast user switching, remote
> ssh logins, etc.
>
> The other mode is the system-wide daemon mode. This follows more the
> traditional unix model of a dedicated pulse user running a daemon to
> which other users can connect. The system mode is more applicable to
> an audio server/appliance scenario.
> I have, for example, PulseAudio running as a system daemon on a
> dedicated server, connected to several speakers around the house. A
> local MPD process on the server can play music through the pulse
> server, or I can ssh to the box and start an internet radio stream.
> Moreover, sound can be redirected from any desktop to the pulse
> server, so that even the neighbors can enjoy the YouTube clips I'm
> watching.
>
> So when talking about what model PulseAudio uses, it is good to keep
> the distinction between per-user and system-wide mode, which have of
> course very different models.
>
> Maarten
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Maarten Bosmans]

2010/2/9  :
> Maybe I'm wrong. I can't figure out *what* the model is, really. When I click
> on padevchooser's "Configure Local Sound Server" entry, I get a window whose
> "Network Server" tab lets me "enable network access to local sound devices."
> Furthermore, I can set or clear a checkbox for "Don't require authentication."
> But I can find nowhere any description of what this authentication would be.
> The documentation for PulseAudio is pretty weak; it mostly says that "things
> work; just try them out." That's not documentation.

Perhaps the confusion stems from the fact that PulseAudio has two
different modes. The normal per-user mode, which should almost always
be used, uses the model of a single user having access to the hardware
of a single seat. This works great and really polishes the whole
desktop experience, including support for fast user switching, remote
ssh logins, etc.

The other mode is the system-wide daemon mode. This follows more the
traditional unix model of a dedicated pulse user running a daemon to
which other users can connect. The system mode is more applicable to
an audio server/appliance scenario.
I have, for example, PulseAudio running as a system daemon on a
dedicated server, connected to several speakers around the house. A
local MPD process on the server can play music through the pulse
server, or I can ssh to the box and start an internet radio stream.
Moreover, sound can be redirected from any desktop to the pulse
server, so that even the neighbors can enjoy the YouTube clips I'm
watching.

So when talking about what model PulseAudio uses, it is good to keep
the distinction between per-user and system-wide mode, which have of
course very different models.

Maarten
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 10/02/10 08:59 did gyre and gimble:
> On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie  wrote:
>>> Here's another analogy; what about the printer? If printers were
>>> considered a part of the seat, then user Bar wouldn't have more right to
>>> print a document either. (The corresponding spy-on-mic analogy would be
>>> that someone puts a document in a scanner and another user scans it...)
>>>
>>> But printers are more of a system-wide resource, and for some use cases,
>>> so is the soundcard. And then, sharing makes sense. If another user is
>>> allowed to print a document while I'm logged in, why shouldn't he be
>>> able to play a sound? So would then the solution be to run PA as a
>>> system-wide daemon, and possibly assign soundcards to it via udev?
>>
>> It's a fair enough point, but I don't think that sound and printers are
>> so alike. Even the scanner example AFAIK would fall under the current PA
>> setup - I believe that sane accesses them on a per-user basis with
>> appropriate ACLs on the device..
>>
>> /me checks
>>
>> [co...@jimmy ~]$ su test
>> Password:
>> [t...@jimmy colin]$ scanimage -L
>> libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied.
>> libusb requires write access to USB device nodes.
>>
> 
> this is another wrong assumption, libusb uses raw USB access, if every
> user would have access
> to USB some devices might be damaged.
> Sane would need to be serverbased, full raw access to the usb bus
> would seriously be a security
> risk (imagine RAW USB access to a USB harddisk).

I fail to see where my assumption is here.

Console-Kit has applied appropriate ACLs to the device node. That was my
point and it was correct. No assumption stated nor needed as to what
happens further down the stack.

[t...@jimmy colin]$ getfacl /dev/bus/usb/005/011
getfacl: Removing leading '/' from absolute path names
# file: dev/bus/usb/005/011
# owner: root
# group: root
user::rw-
user:colin:rw-
group::rw-
mask::rw-
other::r--


The same is true of audio devices. What if multiple users were allowed
direct access. Someone may design a security system with an alarm driven
from the sound system but some other user has come in and hogged the
device and as it does not support hardware mixing the "nuclear reactor
meltdown in 5mins" alarm does not sound and we all die a horrible firey
death. That's worse than a HD failure :p


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 10/02/10 06:51 did gyre and gimble:
> Also imagine TV tuners, webcams are basically handled the same way.
> One user might want to capture a TV movie, while the other one doesn't
> need access to it.

The user may want to do that but it doesn't mean that they should.

I mean seriously, how many users really want to do this? We're talking
about network use here - multiseat stuff and user switching works fine
so we're specifically saying that someone wants to SSH in and take
control of the webcam.

For tv tuners there is typically a middleware involed - e.g. mythbackend
or vdr etc. so doesn't really apply.

> The ck assignment would not be valid for this.

I disagree.

> Now imagine we have a DVB device, multiple users can access the same TV 
> channel.
> While another user might stream or capture the TV content the user
> sitting behind the PC might watch
> the current tuned in TV channel. This is a not so unlikely scenario
> with our devices.

So use mythbackend + mythfrontend or vdr+vdr-receiver or whatever ti's
called.

> This is also just another example where the MS-DOS like single user
> scenario does not fit.

Dude, WTF? Seriously, stop spouting rubbish. My whole comment here has
been about multi-user setups and controlled handover of permissions
between users when appropriate. This is a million miles away form a
"single user scenario". The fact we don't agree that the system should
be open up to abuse from any user who happens to have access does not
make this anything like MS-DOS. If you want to be taken seriously in a
discussion, keep your points valid and on topic.




Here is a (horrible) suggestion. How about this:
 1. Implement a Request Permission call in console-kit.
 2. When an SSH user logs in, and tried to access a device, they can
fire of the "Request Permission" API in CK.
 3. A ck-agent-gui running as the active user fires up a dialog asking.
"User Bob is asking for permission to use . This will
mean you no longer have access to this device until Bob is done with it.
Do you want to let him have it?"

That way the user who has the right to use the device can gracefully
hand over that right to another user. Personally I think this is
horrible, intrusive and fairly ugly and would be a whole framework
designed to cater for a very niche use case and thus would ultimately be
buggy and likely contain security holes.


Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie  wrote:
> 'Twas brillig, and David Henningsson at 10/02/10 06:14 did gyre and gimble:
>> Colin Guthrie wrote:
>>> 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
 I wrote down a few use cases here, I'm sure there are more:

 https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio
>>>
>>> For user Foo, the sound card sounds like it's dedicated for Foo. If this
>>> is the case the a udev rule should be written to ensure that only Foo
>>> has ACL rights on this file and any console-kit udev-acl callouts are
>>> ignored.
>>
>> That makes sense, thanks. I added that reply to the blueprint.
>>
>>> For user Bar, I feel this is invalid. Why should user Bar have the right
>>> to output a sound any more than he has the right to display a popup
>>> window on my desktop?
>>
>> Here's another analogy; what about the printer? If printers were
>> considered a part of the seat, then user Bar wouldn't have more right to
>> print a document either. (The corresponding spy-on-mic analogy would be
>> that someone puts a document in a scanner and another user scans it...)
>>
>> But printers are more of a system-wide resource, and for some use cases,
>> so is the soundcard. And then, sharing makes sense. If another user is
>> allowed to print a document while I'm logged in, why shouldn't he be
>> able to play a sound? So would then the solution be to run PA as a
>> system-wide daemon, and possibly assign soundcards to it via udev?
>
> It's a fair enough point, but I don't think that sound and printers are
> so alike. Even the scanner example AFAIK would fall under the current PA
> setup - I believe that sane accesses them on a per-user basis with
> appropriate ACLs on the device..
>
> /me checks
>
> [co...@jimmy ~]$ su test
> Password:
> [t...@jimmy colin]$ scanimage -L
> libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied.
> libusb requires write access to USB device nodes.
>

this is another wrong assumption, libusb uses raw USB access, if every
user would have access
to USB some devices might be damaged.
Sane would need to be serverbased, full raw access to the usb bus
would seriously be a security
risk (imagine RAW USB access to a USB harddisk).


Best Regards,
Markus

> No scanners were identified. If you were expecting something different,
> check that the scanner is plugged in, turned on and detected by the
> sane-find-scanner tool (if appropriate). Please read the documentation
> which came with this software (README, FAQ, manpages).
> [t...@jimmy colin]$ exit
> [co...@jimmy ~]$ scanimage -L
> device `plustek:libusb:005:011' is a Canon CanoScan LiDE25 flatbed scanner
>
> So yes, scanning is the same as sound right now. That's how ConsoleKit
> works. Printing is handled by cups and user access rights are handled
> therein.
>
> So there is nothing specifically wrong with the approach taken by cups,
> but by the same token, if every single subsystem implemented it's own
> system wide daemon and user authentication system we'd have a hell of a
> mess. As printing is quite often a network resource, then some kind of
> public facing daemon makes sense here.
>
> Standardising on the use of ConsoleKit makes a lot of sense.
>
>>> As for multi-seat, this is already in hand. Console-Kit has support for
>>> multi-seat stuff (tho' it may not be complete - I'm not overly sure
>>> here). What may still remain to be done is to tag certain devices as
>>> being for particular seats so that console-kit/udev can apply the
>>> appropriate ACLs when the set becomes active for a given user. All the
>>> multi-seat stuff is below PA tho' We'll just honour what it tells us. I
>>> don't think we don't need to add specific support for it.
>>
>> And the way ck/udev tells PA what devices it can use, is through device
>> permissions?
>
> Yeah, if we have permission on the device, we use it, otherwise it's
> ignored. When users are switched away, CK fires off dbus signals and we
> recheck our device access etc. We don't accept any input from alsa when
> we do not have permission on the device (even tho' we can read mixer
> settings). If we were able to access the device when we were started but
> subsequently have our permission removed, this is indicative of "user
> switching" (i.e. "Show Login Window" or "Switch User" or "Log in as a
> Different User") in which case we cork any streams tied to those devices
> we can no longer access until such times as they become available to us
> again.
>
> Col
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
>  Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
>  Mandriva Linux Contributor [http://www.mandriva.com/]
>  PulseAudio Hacker [http://www.pulseaudio.org/]
>  Trac Hacker [http://trac.edgewall.org/]
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tan

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and David Henningsson at 10/02/10 06:14 did gyre and gimble:
> Colin Guthrie wrote:
>> 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
>>> I wrote down a few use cases here, I'm sure there are more:
>>>
>>> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio
>>
>> For user Foo, the sound card sounds like it's dedicated for Foo. If this
>> is the case the a udev rule should be written to ensure that only Foo
>> has ACL rights on this file and any console-kit udev-acl callouts are
>> ignored.
> 
> That makes sense, thanks. I added that reply to the blueprint.
> 
>> For user Bar, I feel this is invalid. Why should user Bar have the right
>> to output a sound any more than he has the right to display a popup
>> window on my desktop? 
> 
> Here's another analogy; what about the printer? If printers were
> considered a part of the seat, then user Bar wouldn't have more right to
> print a document either. (The corresponding spy-on-mic analogy would be
> that someone puts a document in a scanner and another user scans it...)
> 
> But printers are more of a system-wide resource, and for some use cases,
> so is the soundcard. And then, sharing makes sense. If another user is
> allowed to print a document while I'm logged in, why shouldn't he be
> able to play a sound? So would then the solution be to run PA as a
> system-wide daemon, and possibly assign soundcards to it via udev?

It's a fair enough point, but I don't think that sound and printers are
so alike. Even the scanner example AFAIK would fall under the current PA
setup - I believe that sane accesses them on a per-user basis with
appropriate ACLs on the device..

/me checks

[co...@jimmy ~]$ su test
Password:
[t...@jimmy colin]$ scanimage -L
libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied.
libusb requires write access to USB device nodes.

No scanners were identified. If you were expecting something different,
check that the scanner is plugged in, turned on and detected by the
sane-find-scanner tool (if appropriate). Please read the documentation
which came with this software (README, FAQ, manpages).
[t...@jimmy colin]$ exit
[co...@jimmy ~]$ scanimage -L
device `plustek:libusb:005:011' is a Canon CanoScan LiDE25 flatbed scanner

So yes, scanning is the same as sound right now. That's how ConsoleKit
works. Printing is handled by cups and user access rights are handled
therein.

So there is nothing specifically wrong with the approach taken by cups,
but by the same token, if every single subsystem implemented it's own
system wide daemon and user authentication system we'd have a hell of a
mess. As printing is quite often a network resource, then some kind of
public facing daemon makes sense here.

Standardising on the use of ConsoleKit makes a lot of sense.

>> As for multi-seat, this is already in hand. Console-Kit has support for
>> multi-seat stuff (tho' it may not be complete - I'm not overly sure
>> here). What may still remain to be done is to tag certain devices as
>> being for particular seats so that console-kit/udev can apply the
>> appropriate ACLs when the set becomes active for a given user. All the
>> multi-seat stuff is below PA tho' We'll just honour what it tells us. I
>> don't think we don't need to add specific support for it. 
> 
> And the way ck/udev tells PA what devices it can use, is through device
> permissions?

Yeah, if we have permission on the device, we use it, otherwise it's
ignored. When users are switched away, CK fires off dbus signals and we
recheck our device access etc. We don't accept any input from alsa when
we do not have permission on the device (even tho' we can read mixer
settings). If we were able to access the device when we were started but
subsequently have our permission removed, this is indicative of "user
switching" (i.e. "Show Login Window" or "Switch User" or "Log in as a
Different User") in which case we cork any streams tied to those devices
we can no longer access until such times as they become available to us
again.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Wed, Feb 10, 2010 at 7:14 AM, David Henningsson
 wrote:
> Colin Guthrie wrote:
>> 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
>>> I wrote down a few use cases here, I'm sure there are more:
>>>
>>> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio
>>
>> For user Foo, the sound card sounds like it's dedicated for Foo. If this
>> is the case the a udev rule should be written to ensure that only Foo
>> has ACL rights on this file and any console-kit udev-acl callouts are
>> ignored.
>
> That makes sense, thanks. I added that reply to the blueprint.
>
>> For user Bar, I feel this is invalid. Why should user Bar have the right
>> to output a sound any more than he has the right to display a popup
>> window on my desktop?
>
> Here's another analogy; what about the printer? If printers were
> considered a part of the seat, then user Bar wouldn't have more right to
> print a document either. (The corresponding spy-on-mic analogy would be
> that someone puts a document in a scanner and another user scans it...)
>
> But printers are more of a system-wide resource, and for some use cases,
> so is the soundcard. And then, sharing makes sense. If another user is
> allowed to print a document while I'm logged in, why shouldn't he be
> able to play a sound? So would then the solution be to run PA as a
> system-wide daemon, and possibly assign soundcards to it via udev?
>

Also imagine TV tuners, webcams are basically handled the same way.
One user might want to capture a TV movie, while the other one doesn't
need access to it.
The ck assignment would not be valid for this.
Now imagine we have a DVB device, multiple users can access the same TV channel.
While another user might stream or capture the TV content the user
sitting behind the PC might watch
the current tuned in TV channel. This is a not so unlikely scenario
with our devices.
This is also just another example where the MS-DOS like single user
scenario does not fit.

Best Regards,
Markus

>> If either scenario is to be supported, then what I
>> suggested elsewhere in this thread is still valid I reckon. i.e
>> something needs to be run as the active user that acts as an agent for
>> some kind of (system?) service that actually generates said alarm. The
>> agent will be running as the active user and it will be responsible for
>> playing the sound/displaying the popup.
>
> Right, this would make sense for some use cases as well and worth
> considering.
>
>> As for multi-seat, this is already in hand. Console-Kit has support for
>> multi-seat stuff (tho' it may not be complete - I'm not overly sure
>> here). What may still remain to be done is to tag certain devices as
>> being for particular seats so that console-kit/udev can apply the
>> appropriate ACLs when the set becomes active for a given user. All the
>> multi-seat stuff is below PA tho' We'll just honour what it tells us. I
>> don't think we don't need to add specific support for it.
>
> And the way ck/udev tells PA what devices it can use, is through device
> permissions?
>
> // David
>
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[David Henningsson]

Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
>> I wrote down a few use cases here, I'm sure there are more:
>>
>> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio
> 
> For user Foo, the sound card sounds like it's dedicated for Foo. If this
> is the case the a udev rule should be written to ensure that only Foo
> has ACL rights on this file and any console-kit udev-acl callouts are
> ignored.

That makes sense, thanks. I added that reply to the blueprint.

> For user Bar, I feel this is invalid. Why should user Bar have the right
> to output a sound any more than he has the right to display a popup
> window on my desktop? 

Here's another analogy; what about the printer? If printers were
considered a part of the seat, then user Bar wouldn't have more right to
print a document either. (The corresponding spy-on-mic analogy would be
that someone puts a document in a scanner and another user scans it...)

But printers are more of a system-wide resource, and for some use cases,
so is the soundcard. And then, sharing makes sense. If another user is
allowed to print a document while I'm logged in, why shouldn't he be
able to play a sound? So would then the solution be to run PA as a
system-wide daemon, and possibly assign soundcards to it via udev?

> If either scenario is to be supported, then what I
> suggested elsewhere in this thread is still valid I reckon. i.e
> something needs to be run as the active user that acts as an agent for
> some kind of (system?) service that actually generates said alarm. The
> agent will be running as the active user and it will be responsible for
> playing the sound/displaying the popup.

Right, this would make sense for some use cases as well and worth
considering.

> As for multi-seat, this is already in hand. Console-Kit has support for
> multi-seat stuff (tho' it may not be complete - I'm not overly sure
> here). What may still remain to be done is to tag certain devices as
> being for particular seats so that console-kit/udev can apply the
> appropriate ACLs when the set becomes active for a given user. All the
> multi-seat stuff is below PA tho' We'll just honour what it tells us. I
> don't think we don't need to add specific support for it. 

And the way ck/udev tells PA what devices it can use, is through device
permissions?

// David


___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
> I wrote down a few use cases here, I'm sure there are more:
> 
> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio

For user Foo, the sound card sounds like it's dedicated for Foo. If this
is the case the a udev rule should be written to ensure that only Foo
has ACL rights on this file and any console-kit udev-acl callouts are
ignored.


For user Bar, I feel this is invalid. Why should user Bar have the right
to output a sound any more than he has the right to display a popup
window on my desktop? If either scenario is to be supported, then what I
suggested elsewhere in this thread is still valid I reckon. i.e
something needs to be run as the active user that acts as an agent for
some kind of (system?) service that actually generates said alarm. The
agent will be running as the active user and it will be responsible for
playing the sound/displaying the popup.


As for multi-seat, this is already in hand. Console-Kit has support for
multi-seat stuff (tho' it may not be complete - I'm not overly sure
here). What may still remain to be done is to tag certain devices as
being for particular seats so that console-kit/udev can apply the
appropriate ACLs when the set becomes active for a given user. All the
multi-seat stuff is below PA tho' We'll just honour what it tells us. I
don't think we don't need to add specific support for it.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[David Henningsson]

Colin Guthrie wrote:
> 'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble:
> This whole thing has been discussed to death, and I really don't feel
> like being drawn into the whole thing again.

>From what I've read here, I'm afraid it's going to keep coming up until
we solve it somehow.

There are just too many people for where the ordinary PA setup (all
soundcards are of exclusive use to the person logged into the current X
session) is not acceptable, and worse, it isn't easy for them to either
reconfigure PA, or replace PA, with something that suits their needs.

I wrote down a few use cases here, I'm sure there are more:

https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio

Let's hope we can get something constructive out of this, and I'm
hopeful we can solve those people's problems, without sacrificing
latency, power usage or security.

// David

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Michał Sawicz at 09/02/10 20:57 did gyre and gimble:
> Dnia 2010-02-09, wto o godzinie 19:31 +, Colin Guthrie pisze:
>> I wouldn't call this overdesign. Quite the opposite. Yes to get this
>> rather bizarre scenario working it would be complex, but to make it
>> work
>> out of the box in this way in PA itself is far from simple. I've
>> already
>> listed the 5 relevant points that would need addressing for this to
>> work
>> and there are significant design hurdles to overcome there. That is
>> what
>> I would consider overdesign - doing something very complex to support
>> a
>> pretty niche use case. 
> 
> It might drop in the same 'overdesigned' category, but maybe it would be
> possible to create a scenario where:
> 
> 1. remote user or a daemon wants to play audio
> 2. PA looks for an active user session on local PC
> 3. the remote user's PA tries to connect (over native protocol) to the
> active user session
> 4. there's a dialog on the active user's session with 'User  tries
> to access your audio equipment with application , allow / deny?'
> 5. if the active user agrees, the remote user is able to play, otherwise
> it remains corked until the active user changes or allows the stream to
> play.
> 
> This would also simplify how remote tunnels are created - now you can
> either turn off authentication or hack the config file to only allow
> certain 


This is possible but not with the current structure. Until the
authentication is successful, there can be no stream and thus it cannot
be corked... but the principle is not all bad and with luck the
notification framework I'll eventually commit will help with part of
this approach should it be undertaken.

That said, I'm not sure the complications resulting from this approach
are really worth the benefits. I think we should concentrate on getting
the typical use cases working as near to perfect as possible before
devoting too much time on rather more exotic multi-user interaction
scenarios.


> Oh, and apart from VoIP calls being eavesdropped, if someone hacks in
> and has access to the hardware he can hear _everything_ that is said
> near the microphone. Big problem. Not even root should be able to do
> that.

Couldn't agree more :)

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Michał Sawicz]

Dnia 2010-02-09, wto o godzinie 21:57 +0100, Michał Sawicz pisze:
> 4. there's a dialog on the active user's session with 'User  tries
> to access your audio equipment with application , allow / deny?'
> 5. if the active user agrees, the remote user is able to play,
> otherwise
> it remains corked until the active user changes or allows the stream
> to
> play. 

Vino-server behaves in a similar manner and for me it seems like quite a
nice manner. Password authentication could be used, too.

-- 
Pozdrawiam
Michał (Saviq) Sawicz


signature.asc
Description: To jest część  wiadomości podpisana cyfrowo
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Michał Sawicz]

Dnia 2010-02-09, wto o godzinie 19:31 +, Colin Guthrie pisze:
> I wouldn't call this overdesign. Quite the opposite. Yes to get this
> rather bizarre scenario working it would be complex, but to make it
> work
> out of the box in this way in PA itself is far from simple. I've
> already
> listed the 5 relevant points that would need addressing for this to
> work
> and there are significant design hurdles to overcome there. That is
> what
> I would consider overdesign - doing something very complex to support
> a
> pretty niche use case. 

It might drop in the same 'overdesigned' category, but maybe it would be
possible to create a scenario where:

1. remote user or a daemon wants to play audio
2. PA looks for an active user session on local PC
3. the remote user's PA tries to connect (over native protocol) to the
active user session
4. there's a dialog on the active user's session with 'User  tries
to access your audio equipment with application , allow / deny?'
5. if the active user agrees, the remote user is able to play, otherwise
it remains corked until the active user changes or allows the stream to
play.

This would also simplify how remote tunnels are created - now you can
either turn off authentication or hack the config file to only allow
certain 

Oh, and apart from VoIP calls being eavesdropped, if someone hacks in
and has access to the hardware he can hear _everything_ that is said
near the microphone. Big problem. Not even root should be able to do
that.

-- 
Cheers
Michał (Saviq) Sawicz


signature.asc
Description: To jest część  wiadomości podpisana cyfrowo
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble:
> On Tue, Feb 9, 2010 at 09:41, Tanu Kaskinen  > wrote:
> 
> That's easier said than done. Only one process can have direct access to
> the sound card at a time. Each user has his own pulseaudio instance
> running. How do you implement constant access in such scenario? I fear
> it would require a major redesign effort in pulseaudio. I haven't seen
> any concrete design proposals enabling simultaneous access for multiple
> users while at the same time retaining all the desirable properties that
> the current system has.
> 
> 
> Off the top of my head
> 
> "root" or other system-level pulseaudio instance opens and owns the
> physical hardware for the entire time a computer is up.
> 
> All the user pulseaudio instances connect through that.
> 
> What's the downside here?

Mainly due to latencies resulting from the IPC mechanism. Currently PA
operates a zero-copy core, but this would likely introduce data copying.

Also user access would then have to be governed by the PA process. Which
user is allowed to access it and for which devices. Console-kit
integration could be used to say which users are active, so we could
authenticate that way in some capacity but how do you implement
multi-seat device allocation with a single PA process?

There are likely many other problems too but you'll probably have to
wait for Lennarts comments to get a full picture.

> Alternatively, rely on the underlying layer to do multiplexing. If the
> hardware supports it, awesome. If it doesn't, let dmix handle it.

Dmix is very smart but it does not support the power saving features
possible in PA.


This whole thing has been discussed to death, and I really don't feel
like being drawn into the whole thing again.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 09/02/10 19:07 did gyre and gimble:
>>> How about a FM USB Transceiver which uses UAC (USB Audio Class)
>>> Why the heck should only the person sitting infront of it be allowed to use 
>>> it
>>> The person sitting infront of it could listen to audio while another
>>> one could transmit audio (I do have such an engineering sample here).
>>
>> So you transmit something in the clear and you are suprised that someone
>> "hijacks" your data? Again the relevance to this discussion is lost on
>> me I'm afraid.
>>
> 
> the user sitting infront of it could listen to FM radio, while another
> one is using the FM Transmit (line-out)
> unit.
> In your scenario such devices do not exist and are prohibited.

If this is how the device is designed to be used, then it should present
itself as two separate devices to the kernel and appropriate ACLs could
be placed on each to allow different users to access it simultaneously.

>>> I see your 'designed' way just as a valid usecase as my one (which
>>> basically was requested multiple times by multiple
>>> people already).
>>
>> Personally I don't. The active user has control of the sound hardware.
>> If the machine is "inactive" then a pseudo session can be registered
>> (i.e. in the case of gdm login). If the active user (be it a real user
>> or "gdm") decides he wants the audio from the lower level system then
>> they should configure their system to recieve the audio via some kind of
>> controlled IPC mechinism and play it back accordingly.
>>
>> Bypassing this layer and accessing things directly is not IMO a good
>> design. Everything is possible with the appropriate mechanisms in place
>> and no functionality is sacrificed, but you have to be prepared to
>> accept that old approaches will not last forever nor survive the tests
>> of time.
> 
> your scenario is definitely over engineered for many people out there.

I wouldn't call this overdesign. Quite the opposite. Yes to get this
rather bizarre scenario working it would be complex, but to make it work
out of the box in this way in PA itself is far from simple. I've already
listed the 5 relevant points that would need addressing for this to work
and there are significant design hurdles to overcome there. That is what
I would consider overdesign - doing something very complex to support a
pretty niche use case.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Jeremy Nickurak]

On Tue, Feb 9, 2010 at 09:41, Tanu Kaskinen  wrote:

> That's easier said than done. Only one process can have direct access to
> the sound card at a time. Each user has his own pulseaudio instance
> running. How do you implement constant access in such scenario? I fear
> it would require a major redesign effort in pulseaudio. I haven't seen
> any concrete design proposals enabling simultaneous access for multiple
> users while at the same time retaining all the desirable properties that
> the current system has.


Off the top of my head

"root" or other system-level pulseaudio instance opens and owns the physical
hardware for the entire time a computer is up.

All the user pulseaudio instances connect through that.

What's the downside here?

Alternatively, rely on the underlying layer to do multiplexing. If the
hardware supports it, awesome. If it doesn't, let dmix handle it.

-- 
Jeremy Nickurak -= Email/XMPP: jer...@nickurak.ca =-
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 7:51 PM, Colin Guthrie  wrote:
> 'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble:
>>> iTunes *requests* nothing. It simply *adheres* to what it has been told
>>> is happening. The same would be true of any application that listens to
>>> the PulseAudio generated cork notifications (IOW what iTunes and VLC are
>>> doing is nigh on identical to what a native PA client can do - i.e. a PA
>>> client that listens for and takes action on cork notifications will
>>> behave like iTunes, one that doesn't have any specific support for
>>> corking will behave like VLC).
>>>
>>
>> something must tell the app to 'cork' in OSX but it it no hard requirement.
>
> It's not the app that corks. The app's audio stream is corked for it and
> the app is told about this. The app does not have any choice in the matter.
>
>> By the way normally only the users who are in the audio group are
>> allowed to access audio (not entirely sure how this is handled with
>> osx though), so it's not like a random user is allowed to access the
>> audio device.
>
> The "audio" group is a legacy and is no longer needed. ACLs on the audio
> device are far more flexible.
>
> Also this only controls *physical* access to the device nodes which
> requires hardware mixing support to actually drive independently. Most
> sound hardware does NOT support hardware mixing.
>
 Seen from my side setting this option (the possibility to lock audio
 to one user) on App level instead of Stack level this would be much
 better.
>>>
>>> No idea what you mean here, but if you are think that I was suggesting
>>> some kind of "iTunes is more capable than VLC" then that's not really
>>> what I'm saying. Both are subject to exactly the same restrictions, it's
>>> just that iTunes presents it to the user by pausing itself and VLC does
>>> not. If iTunes had not paused itself it still would not have been able
>>> to output audio - the core fact does not change - it's simply dealing
>>> with the "you are barred from producing audio" signal that CoreAudio
>>> generated in a more user friendly way.
>>>
>>
>> well something must have told iTunes to pause, but it definitely was
>> not the audio
>> stack which forced iTunes to stop or be silent.
>
> Yes it was. iTunes mearly paused itself because that made sense from a
> UI perspective. The sound system didn't say "Pretty please stop playing
> or I'll cry and cry and cry", it basically held it's hand over it's
> mouth and said "this will be a whole lot easier if you don't scream".
>
>> Sending a notification to the App that it should go into a corking
>> mode (if requested by the app)
>> would be better.
>
> No it wouldn't. Corking is done by the sound system, not by the apps. If
> all apps *had* to implement corking support, then we'd have to
> reimplment *all* apps sound systems. That doesn't make any sense and
> besides, it's not a "preference" or a "nice to have", it's a
> dictatorship-driven "you have had your rights removed" system. This
> isn't something that is specific to PA, it's lower down the stack in
> console kit.
>
 using iTunes and logging in remotely also worked - including audio
 playback. I can make a video of this if you don't believe it heh.
>>>
>>> It doesn't matter if I believe it or not, the fact is that this part of
>>> the model is fundamentally broken and insecure. I mean someone roots
>>> your machine (running as "nobody" or "apache" via some week vuln in
>>> something or other) and all of a sudden they can eavesdrop on all your
>>> VoIP connections??? No thank you.
>>>
>>
>> of course people will capture the audio device, this is a scenario
>> which is 99.9% unlikely.
>
> Yeah you're right, noone would ever be that nasty.
>
>> Maybe you got hacked that way in the past and that's your experience,
>> I have never seen someone hacking a system like that.
>
> Nah, you're right, no one will ever think of doing it and even if they
> did there are probably less than a thousand different ways they could
> exploit this right? Hardly worth bothering about!!
>
>> But imagine even worse people who are in the videogroup are able to
>> enable the webcam! Doh!
>
> Incase you didn't realise the above two comments were sarcastic... your
> point is exactly correct tho'. I don't want any other user to be able to
> view my webcam! That's why the groups are no longer used for device
> access!!! ACLs controlled by console-kit are what permits a given user
> access ot the webcam on any half-way modern desktop. That's the whole
> point!!! Do not have any users in the video group, do not have any users
> in the audio group. In fact I'd go the whole hog and remove those groups
> completely!!
>
>> If someone writes down his password and pins it onto the wall the
>> hacker might know all the passwords - what a terrible
>> scenario!
>
> I don't disagree I'm not entirely sure what your point in relation
> to this discussion is tho'.
>
>
>> How about a FM USB

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble:
>> iTunes *requests* nothing. It simply *adheres* to what it has been told
>> is happening. The same would be true of any application that listens to
>> the PulseAudio generated cork notifications (IOW what iTunes and VLC are
>> doing is nigh on identical to what a native PA client can do - i.e. a PA
>> client that listens for and takes action on cork notifications will
>> behave like iTunes, one that doesn't have any specific support for
>> corking will behave like VLC).
>>
> 
> something must tell the app to 'cork' in OSX but it it no hard requirement.

It's not the app that corks. The app's audio stream is corked for it and
the app is told about this. The app does not have any choice in the matter.

> By the way normally only the users who are in the audio group are
> allowed to access audio (not entirely sure how this is handled with
> osx though), so it's not like a random user is allowed to access the
> audio device.

The "audio" group is a legacy and is no longer needed. ACLs on the audio
device are far more flexible.

Also this only controls *physical* access to the device nodes which
requires hardware mixing support to actually drive independently. Most
sound hardware does NOT support hardware mixing.

>>> Seen from my side setting this option (the possibility to lock audio
>>> to one user) on App level instead of Stack level this would be much
>>> better.
>>
>> No idea what you mean here, but if you are think that I was suggesting
>> some kind of "iTunes is more capable than VLC" then that's not really
>> what I'm saying. Both are subject to exactly the same restrictions, it's
>> just that iTunes presents it to the user by pausing itself and VLC does
>> not. If iTunes had not paused itself it still would not have been able
>> to output audio - the core fact does not change - it's simply dealing
>> with the "you are barred from producing audio" signal that CoreAudio
>> generated in a more user friendly way.
>>
> 
> well something must have told iTunes to pause, but it definitely was
> not the audio
> stack which forced iTunes to stop or be silent.

Yes it was. iTunes mearly paused itself because that made sense from a
UI perspective. The sound system didn't say "Pretty please stop playing
or I'll cry and cry and cry", it basically held it's hand over it's
mouth and said "this will be a whole lot easier if you don't scream".

> Sending a notification to the App that it should go into a corking
> mode (if requested by the app)
> would be better.

No it wouldn't. Corking is done by the sound system, not by the apps. If
all apps *had* to implement corking support, then we'd have to
reimplment *all* apps sound systems. That doesn't make any sense and
besides, it's not a "preference" or a "nice to have", it's a
dictatorship-driven "you have had your rights removed" system. This
isn't something that is specific to PA, it's lower down the stack in
console kit.

>>> using iTunes and logging in remotely also worked - including audio
>>> playback. I can make a video of this if you don't believe it heh.
>>
>> It doesn't matter if I believe it or not, the fact is that this part of
>> the model is fundamentally broken and insecure. I mean someone roots
>> your machine (running as "nobody" or "apache" via some week vuln in
>> something or other) and all of a sudden they can eavesdrop on all your
>> VoIP connections??? No thank you.
>>
> 
> of course people will capture the audio device, this is a scenario
> which is 99.9% unlikely.

Yeah you're right, noone would ever be that nasty.

> Maybe you got hacked that way in the past and that's your experience,
> I have never seen someone hacking a system like that.

Nah, you're right, no one will ever think of doing it and even if they
did there are probably less than a thousand different ways they could
exploit this right? Hardly worth bothering about!!

> But imagine even worse people who are in the videogroup are able to
> enable the webcam! Doh!

Incase you didn't realise the above two comments were sarcastic... your
point is exactly correct tho'. I don't want any other user to be able to
view my webcam! That's why the groups are no longer used for device
access!!! ACLs controlled by console-kit are what permits a given user
access ot the webcam on any half-way modern desktop. That's the whole
point!!! Do not have any users in the video group, do not have any users
in the audio group. In fact I'd go the whole hog and remove those groups
completely!!

> If someone writes down his password and pins it onto the wall the
> hacker might know all the passwords - what a terrible
> scenario!

I don't disagree I'm not entirely sure what your point in relation
to this discussion is tho'.


> How about a FM USB Transceiver which uses UAC (USB Audio Class)
> Why the heck should only the person sitting infront of it be allowed to use it
> The person sitting infront of it could listen to audio while

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 6:54 PM, Colin Guthrie  wrote:
> 'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble:
>>> Can you demonstrate this?
>>>
>>> In the past when I've tested this behaviour on OSX (it was quite a while
>>> ago) it behaves exactly as I described above, and I've literally just
>>> now re-tested this on a colleagues Mac (latest version):
>>>
>>>  1. Enable "Fast User Switching" (System Settings -> Accounts -> Login
>>> Options).
>>>  2. Login as user.
>>>  3. Fast user switch (top right, next to clock) to a different user.
>>>  4. With new user download and run e.g. VLC or iTunes.
>>>  5. Start playing  some tunes.
>>>  6. Fast user switch back to your original user.
>>>  7. Note the blissful silence.
>>>  8. Do whatever you like with the original user login. Play tunes, check
>>> mail etc.
>>>  9. Switch back to the user who *was* playing.
>>>  10. If you used iTunes, it will now be in the Pause state so will be
>>> quiet. If you used VLC the music will continue playing now the user is
>>> active again.
>>>
>>
>> 1. default Mac from a company
>> 2. open a terminal and play an mp3 with mplayer as normal user
>> 3. going to another PC and logging in with ssh (as root) and playing
>> an mp3 ) -- works
>> 4. again going to another PC and in order you cannot blame it on login
>> as root I added another user and played back another mp3 -- it worked
>> too
>> in any case 2 different users were playing back the mp3.
>
>
> This is a totally different scenario to what we were discussing. Please
> try to keep this discussion on topic rather than twisting it to suit
> your particular bugbear.
>
> We've discussed to death the the technical reasons why *simultaneous*
> output from multiple users is not supported and I've shown by example
> that this is the exact same basic behaviour as on OSX with regards to
> multiple users.
>
> You've taken a different example showing that for some bizarre reason, a
> user (root or otherwise) is permitted access to the sound hardware on OSX.
>
> If this is possible (and I have no reason to doubt you) then this is
> simply something that I would argue very strongly *against* wanting to
> support in PA. A random SSH user should *never* have access to various
> h/w devices on my machine. A security model that supports this is broken
> IMHO, regardless of the 0.01% of niche cases where people would like to
> use it.
>
>>> I guess the reason there is a difference between iTunes and VLC is that
>>> iTunes presumably listens to the "cork" notifications from CoreAudio and
>>> issues an application level pause, whereas VLC does not and thus is
>>> forcibly corked, but will automatically play again.
>>>
>>
>> maybe iTunes is requesting this, but then hey this option would be on
>> enduser application level and not at audio stack level.
>
> iTunes *requests* nothing. It simply *adheres* to what it has been told
> is happening. The same would be true of any application that listens to
> the PulseAudio generated cork notifications (IOW what iTunes and VLC are
> doing is nigh on identical to what a native PA client can do - i.e. a PA
> client that listens for and takes action on cork notifications will
> behave like iTunes, one that doesn't have any specific support for
> corking will behave like VLC).
>

something must tell the app to 'cork' in OSX but it it no hard requirement.
By the way normally only the users who are in the audio group are
allowed to access audio (not entirely sure how this is handled with
osx though), so it's not like a random user is allowed to access the
audio device.

>> Seen from my side setting this option (the possibility to lock audio
>> to one user) on App level instead of Stack level this would be much
>> better.
>
> No idea what you mean here, but if you are think that I was suggesting
> some kind of "iTunes is more capable than VLC" then that's not really
> what I'm saying. Both are subject to exactly the same restrictions, it's
> just that iTunes presents it to the user by pausing itself and VLC does
> not. If iTunes had not paused itself it still would not have been able
> to output audio - the core fact does not change - it's simply dealing
> with the "you are barred from producing audio" signal that CoreAudio
> generated in a more user friendly way.
>

well something must have told iTunes to pause, but it definitely was
not the audio
stack which forced iTunes to stop or be silent.
Sending a notification to the App that it should go into a corking
mode (if requested by the app)
would be better.

>>> This is *exactly* the same behaviour as we promote in PulseAudio too.
>>>
>>
>> unfortunately I can not confirm this with iTunes either... I tested
>> this with OSX 10.4 and OSX 10.5.
>>
>> using iTunes and logging in remotely also worked - including audio
>> playback. I can make a video of this if you don't believe it heh.
>
> It doesn't matter if I believe it or not, the fact is that this part of
> the model is fundamentally b

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and olin.pulse@shivers.mail0.org at 09/02/10 00:11
did gyre and gimble:
> OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort
> of get the sense, from this per-user-login server model that PA has the
> horrible one-persone/one-computer model of "the person at the console is the
> person using the computer," which was inflicted on the world by Microsoft
> Windows. If so, this is a real design error, one that doesn't sync up with
> Unix, which has always had a multi-user model of the world.

For X11, PA will follow where the physical *person* is. Even if the App
itself is running remotely, the user is seeing the app on a local
screen. And PA supports exactly the same principle but for sound. Even
tho' the App is running remotely, any sound it produces is heard
*locally*, not remotely.

There is nothing wrong with me logging into my colleagues machine and
running e.g. RhythmnBox on his machine. He currently has full, exclusive
access to his machine's sound hardware, but by virtue of my local
machine running PA and his machine being configured for PA output from
applications, I just SSH in and run the application and the sound it
produces and the display it draws are both heard/seen on *my* computer.
It does not interfere with his computer in any way (other than using
some CPU cycles!) and I never even ask to use his sound h/w.

I've written about the various X11 scenarios here:
http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/

perhaps that'll help explain things a bit.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble:
>> Can you demonstrate this?
>>
>> In the past when I've tested this behaviour on OSX (it was quite a while
>> ago) it behaves exactly as I described above, and I've literally just
>> now re-tested this on a colleagues Mac (latest version):
>>
>>  1. Enable "Fast User Switching" (System Settings -> Accounts -> Login
>> Options).
>>  2. Login as user.
>>  3. Fast user switch (top right, next to clock) to a different user.
>>  4. With new user download and run e.g. VLC or iTunes.
>>  5. Start playing  some tunes.
>>  6. Fast user switch back to your original user.
>>  7. Note the blissful silence.
>>  8. Do whatever you like with the original user login. Play tunes, check
>> mail etc.
>>  9. Switch back to the user who *was* playing.
>>  10. If you used iTunes, it will now be in the Pause state so will be
>> quiet. If you used VLC the music will continue playing now the user is
>> active again.
>>
> 
> 1. default Mac from a company
> 2. open a terminal and play an mp3 with mplayer as normal user
> 3. going to another PC and logging in with ssh (as root) and playing
> an mp3 ) -- works
> 4. again going to another PC and in order you cannot blame it on login
> as root I added another user and played back another mp3 -- it worked
> too
> in any case 2 different users were playing back the mp3.


This is a totally different scenario to what we were discussing. Please
try to keep this discussion on topic rather than twisting it to suit
your particular bugbear.

We've discussed to death the the technical reasons why *simultaneous*
output from multiple users is not supported and I've shown by example
that this is the exact same basic behaviour as on OSX with regards to
multiple users.

You've taken a different example showing that for some bizarre reason, a
user (root or otherwise) is permitted access to the sound hardware on OSX.

If this is possible (and I have no reason to doubt you) then this is
simply something that I would argue very strongly *against* wanting to
support in PA. A random SSH user should *never* have access to various
h/w devices on my machine. A security model that supports this is broken
IMHO, regardless of the 0.01% of niche cases where people would like to
use it.

>> I guess the reason there is a difference between iTunes and VLC is that
>> iTunes presumably listens to the "cork" notifications from CoreAudio and
>> issues an application level pause, whereas VLC does not and thus is
>> forcibly corked, but will automatically play again.
>>
> 
> maybe iTunes is requesting this, but then hey this option would be on
> enduser application level and not at audio stack level.

iTunes *requests* nothing. It simply *adheres* to what it has been told
is happening. The same would be true of any application that listens to
the PulseAudio generated cork notifications (IOW what iTunes and VLC are
doing is nigh on identical to what a native PA client can do - i.e. a PA
client that listens for and takes action on cork notifications will
behave like iTunes, one that doesn't have any specific support for
corking will behave like VLC).

> Seen from my side setting this option (the possibility to lock audio
> to one user) on App level instead of Stack level this would be much
> better.

No idea what you mean here, but if you are think that I was suggesting
some kind of "iTunes is more capable than VLC" then that's not really
what I'm saying. Both are subject to exactly the same restrictions, it's
just that iTunes presents it to the user by pausing itself and VLC does
not. If iTunes had not paused itself it still would not have been able
to output audio - the core fact does not change - it's simply dealing
with the "you are barred from producing audio" signal that CoreAudio
generated in a more user friendly way.

>> This is *exactly* the same behaviour as we promote in PulseAudio too.
>>
> 
> unfortunately I can not confirm this with iTunes either... I tested
> this with OSX 10.4 and OSX 10.5.
> 
> using iTunes and logging in remotely also worked - including audio
> playback. I can make a video of this if you don't believe it heh.

It doesn't matter if I believe it or not, the fact is that this part of
the model is fundamentally broken and insecure. I mean someone roots
your machine (running as "nobody" or "apache" via some week vuln in
something or other) and all of a sudden they can eavesdrop on all your
VoIP connections??? No thank you.

At all user facing levels, for the 99.9% use case of desktop users, we
behave exactly the same as OSX. In the niche case of SSH user logging
in, we DO NOT support the SSH user having control of our sound hardware,
and for good reason.

If you wanted this second senario to be supported you would have to:

 1) Convince the people in charge that this is a good idea.
 2) Design a new layer that runs as a system service and takes exclusive
control of the physical sound h/w. This would have to support the

Re: [pulseaudio-discuss] system-wide daemon

[Nix]

On 9 Feb 2010, olin verbalised:

> OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort
> of get the sense, from this per-user-login server model that PA has the
> horrible one-persone/one-computer model of "the person at the console is the
> person using the computer," which was inflicted on the world by Microsoft
> Windows. If so, this is a real design error, one that doesn't sync up with
> Unix, which has always had a multi-user model of the world.

The model is 'the person at the console is the person near the speakers
and thus the person who should get sound output when requested'. This
doesn't seem like a terribly unrealistic model to me. How many computers
do you know of which have speakers in a completely different place to the
keyboard and screen?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Fred Frigerio]

They way I worked out a similar situation (I am doing an ssh from the box
into the box and sometimes from a different box into it) was to setup the PA
of the user I ssh as and it IS a user that I would never login directly as
to use PA over the network. So as long as someone is logged in then it's PA
works. You could have a couple of different configurations sitting around
and do some shell trickery and start different configurations depending on
the environment.

Does PA support conditional config files? Maybe it can be all kept in the PA
file and just set an environment variable.

Fred F



On Tue, Feb 9, 2010 at 11:59 AM, Markus Rechberger wrote:

> On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox  wrote:
> > The corking stuff in PA is very cool.  I don't think anyone objects to
> > it.  But couldn't we quell all the "PA stinks!" posts by just allowing
> > some processes/groups/users to have constant access to audio?
> >
> > Comparisons to MAC and Windows have been going on for a while, and the
> > PA guys are basically right that PA is more like Windows and Mac than
> > the older sound systems.  If I'm not mistaken, the real issue is all
> > the very valid reasons people out in Linux land have for multi-user
> > simultaneous access to sound.  I'd say those guys are generating most
> > of the negative PA e-mails I read, and not just on this forum.
> >
>
> you cannot compare it with mac, on mac multiuser access works like it
> worked with alsa and OSS.
> The only point is that this behavior should be considered to be fixed
> up again in future.
> I would not wonder if a remote login in windows as a different
> permitted user would provide audio support.
> I do agree that when the user behind the PC is switched that those
> audio instances should be exclusive.
> But remote terminals are a different topic and should be handled different.
> the problem I see with that design is that as soon as the user logs
> out the PA process might vanish again
> so you are really stuck with the system daemon if you want to get
> multiuser support.
> although another possibility might that other PA daemons connect to
> the first PA instance and just pass through
> the first instance might do some user accounting and only shut down
> when all other PA instances are gone
> but in that case the system wide mode seems to be more elegant again...
>
> Markus
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox  wrote:
> The corking stuff in PA is very cool.  I don't think anyone objects to
> it.  But couldn't we quell all the "PA stinks!" posts by just allowing
> some processes/groups/users to have constant access to audio?
>
> Comparisons to MAC and Windows have been going on for a while, and the
> PA guys are basically right that PA is more like Windows and Mac than
> the older sound systems.  If I'm not mistaken, the real issue is all
> the very valid reasons people out in Linux land have for multi-user
> simultaneous access to sound.  I'd say those guys are generating most
> of the negative PA e-mails I read, and not just on this forum.
>

you cannot compare it with mac, on mac multiuser access works like it
worked with alsa and OSS.
The only point is that this behavior should be considered to be fixed
up again in future.
I would not wonder if a remote login in windows as a different
permitted user would provide audio support.
I do agree that when the user behind the PC is switched that those
audio instances should be exclusive.
But remote terminals are a different topic and should be handled different.
the problem I see with that design is that as soon as the user logs
out the PA process might vanish again
so you are really stuck with the system daemon if you want to get
multiuser support.
although another possibility might that other PA daemons connect to
the first PA instance and just pass through
the first instance might do some user accounting and only shut down
when all other PA instances are gone
but in that case the system wide mode seems to be more elegant again...

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Tanu Kaskinen]

ti, 2010-02-09 kello 11:17 -0500, Bill Cox kirjoitti:
> The corking stuff in PA is very cool.  I don't think anyone objects to
> it.  But couldn't we quell all the "PA stinks!" posts by just allowing
> some processes/groups/users to have constant access to audio?

That's easier said than done. Only one process can have direct access to
the sound card at a time. Each user has his own pulseaudio instance
running. How do you implement constant access in such scenario? I fear
it would require a major redesign effort in pulseaudio. I haven't seen
any concrete design proposals enabling simultaneous access for multiple
users while at the same time retaining all the desirable properties that
the current system has.

> I guess the only other really nasty e-mails I read about PA are due to
> old unmaintained code (typically games) that have too much delay in
> PA.  Is there any good reason that the default latency in PA for
> programs that don't bother setting a desired latency is greater than
> zero?

You can't have zero latency, so I assume you mean why don't we use the
smallest latency possible by default. The reason is that low latency
consumes more cpu and battery time.

-- 
Tanu Kaskinen

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

The corking stuff in PA is very cool.  I don't think anyone objects to
it.  But couldn't we quell all the "PA stinks!" posts by just allowing
some processes/groups/users to have constant access to audio?

Comparisons to MAC and Windows have been going on for a while, and the
PA guys are basically right that PA is more like Windows and Mac than
the older sound systems.  If I'm not mistaken, the real issue is all
the very valid reasons people out in Linux land have for multi-user
simultaneous access to sound.  I'd say those guys are generating most
of the negative PA e-mails I read, and not just on this forum.

I guess the only other really nasty e-mails I read about PA are due to
old unmaintained code (typically games) that have too much delay in
PA.  Is there any good reason that the default latency in PA for
programs that don't bother setting a desired latency is greater than
zero?

Bill

On Tue, Feb 9, 2010 at 10:49 AM, Markus Rechberger
 wrote:
> On Tue, Feb 9, 2010 at 4:44 PM, Ng Oon-Ee  wrote:
>> On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote:
>> 
>>> 1. default Mac from a company
>>> 2. open a terminal and play an mp3 with mplayer as normal user
>>> 3. going to another PC and logging in with ssh (as root) and playing
>>> an mp3 ) -- works
>>> 4. again going to another PC and in order you cannot blame it on login
>>> as root I added another user and played back another mp3 -- it worked
>>> too
>>> in any case 2 different users were playing back the mp3.
>> 
>>> using iTunes and logging in remotely also worked - including audio
>>> playback. I can make a video of this if you don't believe it heh.
>> 
>>
>> Am I the only one who sees a bit of a difference between what you and
>> Colin are testing? He's testing fast user switching on the same machine
>> and you're testing remote logins?
>>
>
> no you are right but all together it's only about multiuser audio support.
> I never tested fast user switching, but for this it might make sence
> to lock the audio stack
> even though the corking mechanism is coordinated on app client level
> and not on stack/userlogin level.
>
> Markus
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 4:44 PM, Ng Oon-Ee  wrote:
> On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote:
> 
>> 1. default Mac from a company
>> 2. open a terminal and play an mp3 with mplayer as normal user
>> 3. going to another PC and logging in with ssh (as root) and playing
>> an mp3 ) -- works
>> 4. again going to another PC and in order you cannot blame it on login
>> as root I added another user and played back another mp3 -- it worked
>> too
>> in any case 2 different users were playing back the mp3.
> 
>> using iTunes and logging in remotely also worked - including audio
>> playback. I can make a video of this if you don't believe it heh.
> 
>
> Am I the only one who sees a bit of a difference between what you and
> Colin are testing? He's testing fast user switching on the same machine
> and you're testing remote logins?
>

no you are right but all together it's only about multiuser audio support.
I never tested fast user switching, but for this it might make sence
to lock the audio stack
even though the corking mechanism is coordinated on app client level
and not on stack/userlogin level.

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Ng Oon-Ee]

On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote:

> 1. default Mac from a company
> 2. open a terminal and play an mp3 with mplayer as normal user
> 3. going to another PC and logging in with ssh (as root) and playing
> an mp3 ) -- works
> 4. again going to another PC and in order you cannot blame it on login
> as root I added another user and played back another mp3 -- it worked
> too
> in any case 2 different users were playing back the mp3.

> using iTunes and logging in remotely also worked - including audio
> playback. I can make a video of this if you don't believe it heh.


Am I the only one who sees a bit of a difference between what you and
Colin are testing? He's testing fast user switching on the same machine
and you're testing remote logins?

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

> Can you demonstrate this?
>
> In the past when I've tested this behaviour on OSX (it was quite a while
> ago) it behaves exactly as I described above, and I've literally just
> now re-tested this on a colleagues Mac (latest version):
>
>  1. Enable "Fast User Switching" (System Settings -> Accounts -> Login
> Options).
>  2. Login as user.
>  3. Fast user switch (top right, next to clock) to a different user.
>  4. With new user download and run e.g. VLC or iTunes.
>  5. Start playing  some tunes.
>  6. Fast user switch back to your original user.
>  7. Note the blissful silence.
>  8. Do whatever you like with the original user login. Play tunes, check
> mail etc.
>  9. Switch back to the user who *was* playing.
>  10. If you used iTunes, it will now be in the Pause state so will be
> quiet. If you used VLC the music will continue playing now the user is
> active again.
>

1. default Mac from a company
2. open a terminal and play an mp3 with mplayer as normal user
3. going to another PC and logging in with ssh (as root) and playing
an mp3 ) -- works
4. again going to another PC and in order you cannot blame it on login
as root I added another user and played back another mp3 -- it worked
too
in any case 2 different users were playing back the mp3.

> I guess the reason there is a difference between iTunes and VLC is that
> iTunes presumably listens to the "cork" notifications from CoreAudio and
> issues an application level pause, whereas VLC does not and thus is
> forcibly corked, but will automatically play again.
>

maybe iTunes is requesting this, but then hey this option would be on
enduser application level and not at audio stack level.

Seen from my side setting this option (the possibility to lock audio
to one user) on App level instead of Stack level this would be much
better.

> This is *exactly* the same behaviour as we promote in PulseAudio too.
>

unfortunately I can not confirm this with iTunes either... I tested
this with OSX 10.4 and OSX 10.5.

using iTunes and logging in remotely also worked - including audio
playback. I can make a video of this if you don't believe it heh.

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 09/02/10 08:43 did gyre and gimble:
> On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie  wrote:
>> 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble:
>>> On Tue, Feb 9, 2010 at 3:01 AM,   wrote:
 Bill Cox:
> While the "right" way is not system-wide mode, in practice, I find
> system-wide mode to be very stable and usable on Ubuntu systems that
> have multiple users trying to send sound to the speakers.

 So, I'm still wondering: what *is* the "right way" for this use case? Is it
 the case that PulseAudio just doesn't address it?
>>>
>>> There is no right way pulseaudio was not designed to support multiple
>>> users at the same time (without the depreciated exception of running
>>> it as system wide daemon).
>>
>> Indeed. PA is principally meant to be run per-user. Each user logged in
>> will have their own PA process running and each will monitor a system
>> service called "ConsoleKit" which tracks which user is active. We adhere
>> to whatever ConsoleKit tells us with regards to which user is currently
>> "active" (see ck-list-sessions) and only the active user has access to
>> the sound hardware.
>>
>> Think about how switching users works (on Linux and on Windows/OSX).
>> Only the user whose desktop is currently presented will be allowed to
>> use sound, the other user's sound is "corked" until they become active
>> again.
> 
> 
> Bad example as usual, on OSX everyone (who's permitted to use the
> audio unit) can just log in and use the audio unit.

Can you demonstrate this?

In the past when I've tested this behaviour on OSX (it was quite a while
ago) it behaves exactly as I described above, and I've literally just
now re-tested this on a colleagues Mac (latest version):

 1. Enable "Fast User Switching" (System Settings -> Accounts -> Login
Options).
 2. Login as user.
 3. Fast user switch (top right, next to clock) to a different user.
 4. With new user download and run e.g. VLC or iTunes.
 5. Start playing  some tunes.
 6. Fast user switch back to your original user.
 7. Note the blissful silence.
 8. Do whatever you like with the original user login. Play tunes, check
mail etc.
 9. Switch back to the user who *was* playing.
 10. If you used iTunes, it will now be in the Pause state so will be
quiet. If you used VLC the music will continue playing now the user is
active again.

I guess the reason there is a difference between iTunes and VLC is that
iTunes presumably listens to the "cork" notifications from CoreAudio and
issues an application level pause, whereas VLC does not and thus is
forcibly corked, but will automatically play again.

This is *exactly* the same behaviour as we promote in PulseAudio too.

If you can show me something that proves the above invalid, I'm all
ears, but I'm pretty confident that what I said originally is correct
and the above test seems to support that.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

I think this is one area where PulseAudio could be improved, though I
can't quite figure out how!  Surely, there must be some way to allow
specific processes or users to have full sound access, while otherwise
sticking to the one-user-at-a-time model.

I'm trying to port SBL (another console screen reader) to Ubuntu, now,
and so I've got yet another piece of code that will need substantial
changes to work with the one-user-at-a-time model, in addition to
speechd-up, espeakup, and speech-dispatcher.  Grr...  Can't we just
add the concept of an "allowed" user, who gets to play sound no matter
who's logged in?

Bill

On Tue, Feb 9, 2010 at 3:43 AM, Markus Rechberger  wrote:
> On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie  wrote:
>> 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble:
>>> On Tue, Feb 9, 2010 at 3:01 AM,   wrote:
 Bill Cox:
> While the "right" way is not system-wide mode, in practice, I find
> system-wide mode to be very stable and usable on Ubuntu systems that
> have multiple users trying to send sound to the speakers.

 So, I'm still wondering: what *is* the "right way" for this use case? Is it
 the case that PulseAudio just doesn't address it?
>>>
>>> There is no right way pulseaudio was not designed to support multiple
>>> users at the same time (without the depreciated exception of running
>>> it as system wide daemon).
>>
>> Indeed. PA is principally meant to be run per-user. Each user logged in
>> will have their own PA process running and each will monitor a system
>> service called "ConsoleKit" which tracks which user is active. We adhere
>> to whatever ConsoleKit tells us with regards to which user is currently
>> "active" (see ck-list-sessions) and only the active user has access to
>> the sound hardware.
>>
>> Think about how switching users works (on Linux and on Windows/OSX).
>> Only the user whose desktop is currently presented will be allowed to
>> use sound, the other user's sound is "corked" until they become active
>> again.
>
>
> Bad example as usual, on OSX everyone (who's permitted to use the
> audio unit) can just log in and use the audio unit.
>
> Markus
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie  wrote:
> 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble:
>> On Tue, Feb 9, 2010 at 3:01 AM,   wrote:
>>> Bill Cox:
 While the "right" way is not system-wide mode, in practice, I find
 system-wide mode to be very stable and usable on Ubuntu systems that
 have multiple users trying to send sound to the speakers.
>>>
>>> So, I'm still wondering: what *is* the "right way" for this use case? Is it
>>> the case that PulseAudio just doesn't address it?
>>
>> There is no right way pulseaudio was not designed to support multiple
>> users at the same time (without the depreciated exception of running
>> it as system wide daemon).
>
> Indeed. PA is principally meant to be run per-user. Each user logged in
> will have their own PA process running and each will monitor a system
> service called "ConsoleKit" which tracks which user is active. We adhere
> to whatever ConsoleKit tells us with regards to which user is currently
> "active" (see ck-list-sessions) and only the active user has access to
> the sound hardware.
>
> Think about how switching users works (on Linux and on Windows/OSX).
> Only the user whose desktop is currently presented will be allowed to
> use sound, the other user's sound is "corked" until they become active
> again.


Bad example as usual, on OSX everyone (who's permitted to use the
audio unit) can just log in and use the audio unit.

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Colin Guthrie]

'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble:
> On Tue, Feb 9, 2010 at 3:01 AM,   wrote:
>> Bill Cox:
>>> While the "right" way is not system-wide mode, in practice, I find
>>> system-wide mode to be very stable and usable on Ubuntu systems that
>>> have multiple users trying to send sound to the speakers.
>>
>> So, I'm still wondering: what *is* the "right way" for this use case? Is it
>> the case that PulseAudio just doesn't address it?
> 
> There is no right way pulseaudio was not designed to support multiple
> users at the same time (without the depreciated exception of running
> it as system wide daemon).

Indeed. PA is principally meant to be run per-user. Each user logged in
will have their own PA process running and each will monitor a system
service called "ConsoleKit" which tracks which user is active. We adhere
to whatever ConsoleKit tells us with regards to which user is currently
"active" (see ck-list-sessions) and only the active user has access to
the sound hardware.

Think about how switching users works (on Linux and on Windows/OSX).
Only the user whose desktop is currently presented will be allowed to
use sound, the other user's sound is "corked" until they become active
again.

That is the *right* way and the default way. If you want something
different then you can but you'll have to get your hands a little dirty.

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Tue, Feb 9, 2010 at 3:01 AM,   wrote:
> Bill Cox:
>> While the "right" way is not system-wide mode, in practice, I find
>> system-wide mode to be very stable and usable on Ubuntu systems that
>> have multiple users trying to send sound to the speakers.
>
> So, I'm still wondering: what *is* the "right way" for this use case? Is it
> the case that PulseAudio just doesn't address it?

There is no right way pulseaudio was not designed to support multiple
users at the same time (without the depreciated exception of running
it as system wide daemon).

Markus
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[olin . pulse . 7ia]

Bill Cox:
> While the "right" way is not system-wide mode, in practice, I find
> system-wide mode to be very stable and usable on Ubuntu systems that
> have multiple users trying to send sound to the speakers. 

So, I'm still wondering: what *is* the "right way" for this use case? Is it
the case that PulseAudio just doesn't address it?
-Olin
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Daniel Chen]

On Sun, Feb 7, 2010 at 10:54 PM, Bill Cox  wrote:
> To set system-wide mode:
[...]

The method for Jaunty/Karmic differs slightly from that for Lucid, but
one can always look in /etc/default/pulseaudio for pointers. I try to
keep this file updated.

Best,
-Dan
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] system-wide daemon

[Bill Cox]

While the "right" way is not system-wide mode, in practice, I find
system-wide mode to be very stable and usable on Ubuntu systems that
have multiple users trying to send sound to the speakers.  It's easy
to get Ubuntu Karmic and Lucid to use PulseAudio in system-wide mode.
For systems that require rock-solid sound, and which need to share the
sound card simultaneously with multiple users, it's what I currently
recomend.  Long-term, I believe this situation will change, but for
now, in Ubuntu, system-wide mode would be my recomendation for you.
To set system-wide mode:

Edit /etc/defaults/pulseaudio, and change:
PULSEAUDIO_SYSTEM_START=0
to
PULSEAUDIO_SYSTEM_START=1

Then, edit /etc/pulse/client.conf, and add the line
autospawn = no
After the line that says '#autospawn = yes'.  Then, delete the file
/etc/xdg/autostart/pulseaudio.desktop.

Finally, disable group-based authentication to use the sound system.
Edit /etc/pulse/system.pa.  Find the line that reads:
load-module module-native-protocol-unix
and change it to read:
  load-module module-native-protocol-unix auth-anonymous=1

Be warned that you open yourself up to a unauthorized sound hacker
attacks!  Your wife could send perverse audio over your speakers
without permission!  Your children could spy on you through your mic
without your password!

If you're a bit confused, join the club.  In any case, I my system
works very well in system-wide mode, and for my purposes it works far
better than user-mode, but I've got multiple programs running as
different users that need simultaneous access to the sound card.

Bill

On Sun, Feb 7, 2010 at 6:54 PM,   wrote:
> I am trying to understand PulseAudio, and have some use cases for which
> it's not clear to me how best to configure the system.
>
> In my living room at home, I have a pair of stereo speakers, which are
> connected to a linux box, which, in turn, has some large disks holding a
> large music collection. When you wish to play music in my home, you do
> it by running a program of some sort on this computer.
>
> Now, the thing is that this computer has a monitor, keyboard and mouse.
> Sometimes someone is logged in to this console, doing things on the
> computer. Sometime no one is logged in at all.
>
> Now, as I am typing this very message, I am sitting on my couch in my
> living room, using my notebook computer. What I would also like to do,
> for example, is ssh into my living room server, run rythmbox, and play
> some music. Perhaps my wife is logged in to the console; perhaps she
> isn't. Perhaps I am. That's irrelevant. My music server is a multi-user
> system; multiple people can be simultaneously logged in to the system,
> and all of them should be able to access the audio hardware.
>
> It seems to me that this is the sort of thing for which one wants a
> system-wide pulse daemon. Pulse Audio seems to be tuned towards the
> idea of having a daemon launched per login session. But I would like
> multiple users in my home to be able to remotely connect to my music
> system and run programs that send audio to the speakers. This should
> be completely independent of who is logged in at the console.
>
> On the other hand, I've read the PulseAudio wiki seeking enlightenment,
> and the wiki very clearly disrecommends using PA in system-daemon mode.
> It doesn't make a very compelling case of *why* system-daemon mode is
> a bad idea, it mostly just explains that PA will restrict functionality
> for security reasons if you obstinately insist on doing so.
>
> So, what's the right way to handle the use case I've outlined?
>    -Olin
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] System-wide daemon howto/best practices

[Lennart Poettering]

On Tue, 04.09.07 00:10, Jan Kasprzak ([EMAIL PROTECTED]) wrote:

> : So in
> : the end we might end up with the optional solution of running a
> : tiny/dumbed-down pa system instance which sessions connect to. But
> : that's way down on my TODO list, and will always stay optional since
> : it is detrimental for latency.
> 
>   How bad the latency increase may be for adding another "upstream"
> daemon? Would it still be usable for the interactive communication
> like ekiga?

Yes, most likely. But audio production definitely not. (but I guess
you wouldn't want to do that on such a multi-seat machine
anyway?). Games might be problematic, but should be fine I would guess.

Hmm, something's broken with your email quoting. Your '>' looks like a ':'
to me.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] System-wide daemon howto/best practices

[Jan Kasprzak]

Lennart Poettering wrote:
: Inside RH we had a few disucssions how to handle multi-seat setups
: with regards to audio best. Our conclusion was that audio cards should
: be treated similar to mice and keyboards: i.e. each seat gets its own
: pair of boxes (or a headphone) and they are not shared with anyone
: else. OTOH I see how sharing a sound card would be handy.

Well, I am thinking about (not only) sharing a sound card,
but possibly splitting the (multi-channel) sound card output
to two or more "virtual sound cards", and letting each user
have his own two audio channels. This could be done better
with a system-wide daemon which would handle only mixing the two
inputs to the 4-channel sound card, and maybe a per-user daemon
with other goodies (such as storing the stream volume and name pairs).

: So in
: the end we might end up with the optional solution of running a
: tiny/dumbed-down pa system instance which sessions connect to. But
: that's way down on my TODO list, and will always stay optional since
: it is detrimental for latency.

How bad the latency increase may be for adding another "upstream"
daemon? Would it still be usable for the interactive communication
like ekiga?

Thanks,

-Yenya

-- 
| Jan "Yenya" Kasprzak   |
| GPG: ID 1024/D3498839  Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/ |
** Those who fail to understand communication protocols,  **
** are doomed to repeat them over port 80.-- from /.  **
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: [pulseaudio-discuss] System-wide daemon howto/best practices

[Lennart Poettering]

On Wed, 29.08.07 20:38, Jan Kasprzak ([EMAIL PROTECTED]) wrote:

Hi!

> on my home workstation I use a dual-seated setup (two monitors, two
> keyboards, two VGA cards, etc. - two independent users). I am
> looking for a way of using the sound card by both users
> simultaneously (I have problem that when one user's application
> opens the sound device and keeps it opened, the other user's ekiga
> cannot use it, which is quite annoying especially when receiving an
> incoming call).
> 
> I thought system-wide PulseAudio daemon might be the correct
> answer. I have read
> http://www.pulseaudio.org/wiki/SystemWideInstance,
> but I am not sure about how to best configure it:
> 
> * Is there any prebuilt init script for Fedora? Fedora RPMs does not
>   seem to have any (this is a minor problem, I can write it myself).

Not that I knew of. 

> * How to tell all user's sessions "use this PulseAudio daemon"?
>   Should I set an environment variable PULSE_SERVER somewhere in GDM
>   session startup scripts? Or use the default-server directive in
>   /etc/pulse/client.conf?

You have lot of different options:

You could stick it in /etc/pulse/client.conf (which is probably what
I'd). You could set $PULSE_SERVER. You could leave it out entirely if
the PA daemon is running locally. You could store it in the X11 root
window. (see pax11publish for that) If PULSE_SERVER is not set PA will
try $DISPLAY as a fallback, too. So basically, I did my best to make
it work even without too much manual configuration.

> * What about authentication? Is a pulse-access group membership the
>   recommended way? Or should I copy ~/.pulse-cookie to the home
>   directories of users I want to have access to the system-wide
>   daemon?

Both is fine. pulse-access is probably the best bay though.

> * Should user apps access the system-wide daemon directly? I have
>   also thought about each user having his own daemon, connected to
>   the system-wide one by (e.g.) module-native-protocol-unix.

Each time you add another layer of indirection audio latency becomes
worse. Thus I'd suggest using a single system-wide instance and that
should be it.

OTOH more and more policy is managed by the PA daemons and hence
running it per-session is much better then running it system-wide.

Inside RH we had a few disucssions how to handle multi-seat setups
with regards to audio best. Our conclusion was that audio cards should
be treated similar to mice and keyboards: i.e. each seat gets its own
pair of boxes (or a headphone) and they are not shared with anyone
else. OTOH I see how sharing a sound card would be handy. So in
the end we might end up with the optional solution of running a
tiny/dumbed-down pa system instance which sessions connect to. But
that's way down on my TODO list, and will always stay optional since
it is detrimental for latency.

Lennart

-- 
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/   GnuPG 0x1A015CC4
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss