Heya,
After installing something resembling a Rawhide system and filing plenty of bugs in the course of action, I set myself onto testing PulseAudio today. I was quite scared by the amounts of configuration (some of it non-trivial) and changes to applications to get PulseAudio working as the main sound system (ie. with all applications talking to ALSA-libs talking to PulseAudio, talking to the ALSA backend).
I wanted to have an esound replacement first, so that beeps and warnings could go through PulseAudio, and not hinder the other applications using ALSA.
I encountered a bunch of dependency problems: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230206
Then a warning (which I don't think is critical to testing): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230209
And finally, the big problem, an assert trying to play back some sound: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
Cheers
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Also, keep in mind that we're going to enable accessible login (including screen readers) for gdm - I wonder if we need pulse audio running there and how it works with the alsa-pulse plug-in - will pulse-audio be activated on demand? Or will the presence of alsa-pulse just break accessible login because there's no PA instance running?
Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that.
David
On Tue, 2007-02-27 at 18:30 +0100, Pierre Ossman wrote:
David Zeuthen wrote:
Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that.
Or keep dmix until everything can go through pulse?
I don't think this works with f-u-s. I tried. Thinking about it, wouldn't it would be a security issue if it did work? You really don't want dmix to accepting connections from other users...
David
On 2/27/07, David Zeuthen david@fubar.dk wrote:
On Tue, 2007-02-27 at 18:30 +0100, Pierre Ossman wrote:
David Zeuthen wrote:
Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that.
Or keep dmix until everything can go through pulse?
I don't think this works with f-u-s. I tried. Thinking about it, wouldn't it would be a security issue if it did work? You really don't want dmix to accepting connections from other users...
Of course not. But dmix or a system Pulse, there will be no session partitioning until everyone esle can catch up with these changes.
Monty
On 2/27/07, David Zeuthen david@fubar.dk wrote:
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Actually, it's easy. Set up a system Pulse and everyone can use sound and emulation. What needs to happen next is to implement session partitioning in Pulse, the emulation helpers and emulation daemons.
Pulse should always be running (even if it occasionally releases devices to save battery).
Monty
On Tue, 2007-02-27 at 13:04 -0500, xiphmont@xiph.org wrote:
On 2/27/07, David Zeuthen david@fubar.dk wrote:
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Actually, it's easy. Set up a system Pulse and everyone can use sound and emulation. What needs to happen next is to implement session partitioning in Pulse, the emulation helpers and emulation daemons.
Pulse should always be running (even if it occasionally releases devices to save battery).
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
One of those is that you want to read user settings and enforce policy depending on users session [1].
Another problem is that if you have system-wide daemons you need to coordinate clients with different identities; e.g. you suddenly need to label your objects and make sure that an object created by uid 500 cannot be manipulated by uid 501. Things like that. Does PA handle that already?
For starters, how are all the exiting PA tools going to work with PA running system-wide? How is it going to work with multiple sessions? I don't think there's anything "easy" about this. If it was easy, wouldn't you have RPM's for us already? ;-)
I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol.
David
[1] : see also Lennarts presentation about "Compiz for audio" plans which further marries that idea
http://0pointer.de/blog/projects/freedom-lovers.html
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
Justification by cargo cult. Here's a few reasons per-session Pulse is [relatively] a worse idea:
You lose state on switch. Transitions are abrupt and 'poppy'; think of the X mode changes upon switch. Per session is harder, yields inferior results in the long run, and gives us no path to move to immediately. Impossibility of emulation. Emulation is not optional. We do not make forward progress by throwing all the current users under the bus. This is *the* reason esd was a resounding failure.
One of those is that you want to read user settings and enforce policy depending on users session [1].
Of course. And that's no different if it's done in the session or in the system.
Another problem is that if you have system-wide daemons you need to coordinate clients with different identities; e.g. you suddenly need to label your objects and make sure that an object created by uid 500 cannot be manipulated by uid 501. Things like that. Does PA handle that already?
No, it does not. It will also not currently handle f-u-s as a session daemon either.
For starters, how are all the exiting PA tools going to work with PA running system-wide?
PA has always worked as a system daemon.
How is it going to work with multiple sessions? I don't think there's anything "easy" about this. If it was easy, wouldn't you have RPM's for us already? ;-)
The code is easy. The politics make me want to walk away and never look back.
I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol.
That is actually one possibility up for consideration, but I think needlessly complicated. The problem is not making Pulse work well with f-u-s-- the problem is keeping ALSA, ESD and OSS access working with f-u-s. Remember-- that's everybody right now.
Monty
On 2/27/07, xiphmont@xiph.org xiphmont@xiph.org wrote:
I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol.
That is actually one possibility up for consideration, but I think needlessly complicated.
Rather, I should say the idea up for consideration is a thin authenticator that is the only trusted connection mechanism for a system pulse. That still doesn't directly help out the emulation case though. We can't ship broken stuff, and regressing sound counts as broken.
Monty
On Tue, 2007-02-27 at 13:44 -0500, xiphmont@xiph.org wrote:
On 2/27/07, xiphmont@xiph.org xiphmont@xiph.org wrote:
I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol.
That is actually one possibility up for consideration, but I think needlessly complicated.
Rather, I should say the idea up for consideration is a thin authenticator that is the only trusted connection mechanism for a system pulse.
Yea, that's sort of what I meant. The system-wide bit would just pass a fd over a socket to the per-session pulse.
That still doesn't directly help out the emulation case though.
So, why can't the emulation bits pass the fd from the open(2)'er of /dev/dsp to the right PA instance? These bits could live in the system-wide bit...
We can't ship broken stuff, and regressing sound counts as broken.
There's no regressions if we decide not to use PA by default; things will still just suck as bad as they did for FC6, FC5, FC4 and FC3.
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
Rather, I should say the idea up for consideration is a thin authenticator that is the only trusted connection mechanism for a system pulse.
Yea, that's sort of what I meant. The system-wide bit would just pass a fd over a socket to the per-session pulse.
Backwards.
So, why can't the emulation bits pass the fd from the open(2)'er of /dev/dsp to the right PA instance? These bits could live in the system-wide bit...
Please, no more talk of LD_PRELOAD. I will resign before I pin the future of Linux Audio on an LD_PRELOAD hack. Dead serious. It is a non-starter.
There's no regressions if we decide not to use PA by default; things will still just suck as bad as they did for FC6, FC5, FC4 and FC3.
Sure, problem solved.
Monty
On Tue, 2007-02-27 at 14:07 -0500, xiphmont@xiph.org wrote:
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
Rather, I should say the idea up for consideration is a thin authenticator that is the only trusted connection mechanism for a system pulse.
Yea, that's sort of what I meant. The system-wide bit would just pass a fd over a socket to the per-session pulse.
Backwards.
How about posting a more detailed plan or replying to the one I posted just before. And no manifestos in it this time either - we're not terribly interested in why *you* think OSS is important to support since it can be done by at least two mechanisms if you so desire. Thanks.
David
On Tue, 2007-02-27 at 13:28 -0500, xiphmont@xiph.org wrote:
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
Justification by cargo cult.
Oh please. Keep this discussion technical.
Here's a few reasons per-session Pulse is [relatively] a worse idea:
You lose state on switch. Transitions are abrupt and 'poppy'; think of the X mode changes upon switch.
X is getting fixed. See Keith's blog for this
http://keithp.com/blog/kernel-mode-drivers.html
See also below.
Per session is harder, yields inferior results in the long run, and gives us no path to move to immediately.
Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please.
Impossibility of emulation. Emulation is not optional. We do not make forward progress by throwing all the current users under the bus. This is *the* reason esd was a resounding failure.
Users can use LD_PRELOAD for such broken apps that we can't patch to live in this century. We all know that /dev/dsp is fundamentally broken and no-one but people living stuck in the 90's are using it.
We're a *free software distribution*, we don't have to support legacy crap the nice way. If you want, use LD_PRELOAD hacks. Or some emulation daemon that can forward the stream from then open(2)'er to the right PA instance (not hard).
Another problem is that if you have system-wide daemons you need to coordinate clients with different identities; e.g. you suddenly need to label your objects and make sure that an object created by uid 500 cannot be manipulated by uid 501. Things like that. Does PA handle that already?
No, it does not.
Heck, so uid 501 can poke the streams created by uid 500? That's a show stopper just because of security implications. Do you disagree?
It will also not currently handle f-u-s as a session daemon either.
That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted.
Heck, we're getting revoke() soon (see #230006) so whether the PA instance in a session likes it or not it's going to have access to the sound device revoked. It just needs to cope with that *just like* it needs to cope with devices being hot-removed.
How is it going to work with multiple sessions? I don't think there's anything "easy" about this. If it was easy, wouldn't you have RPM's for us already? ;-)
The code is easy. The politics make me want to walk away and never look back.
Well, there's no politics here apart from wishing not to introduce short-term hacks that will haunt us for ever. See X.org mode setting in user space for a brilliant example of how this hack is STILL HAUNTING US in 2007. Ding ding ding, it's 2007 already!
I think what you want is some system-wide private PA mixer service that only per-session PA instances can connect to over a private protocol.
That is actually one possibility up for consideration, but I think needlessly complicated. The problem is not making Pulse work well with f-u-s-- the problem is keeping ALSA, ESD and OSS access working with f-u-s. Remember-- that's everybody right now.
Yes, we need to sort out this audio situation. Right now PA, until it's fixed in a sensible way, makes f-u-s not work so we can only do one of them. That's not my call though.
What is the view of all this from PA upstream? I talked a lot to Lennart at LCA about this and he said system-wide pulse was a non-starter exactly for the reasons I listed.
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
Oh please. Keep this discussion technical.
I meant exactly what I said. It was not intended as a personal attack.
Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please.
Impossibility of emulation. Emulation is not optional. We do not make forward progress by throwing all the current users under the bus. This is *the* reason esd was a resounding failure.
Users can use LD_PRELOAD for such broken apps that we can't patch to live in this century. We all know that /dev/dsp is fundamentally broken and no-one but people living stuck in the 90's are using it.
LD_PRELOAD is a fragile hack that wasn't enough to save ESD. Either we do things right or we don't do them at all. No more hacks for benefit in the short run. Please.
No, it does not.
Heck, so uid 501 can poke the streams created by uid 500? That's a show stopper just because of security implications. Do you disagree?
I agree it's not acceptible in the mid/long term. However, this is already what Ubuntu and Debian do today.
That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted.
And that's no different than if pulse was a system daemon that listened to dbus.
Heck, we're getting revoke() soon (see #230006) so whether the PA instance in a session likes it or not it's going to have access to the sound device revoked. It just needs to cope with that *just like* it needs to cope with devices being hot-removed.
revoke is just such a .... stunningly... idiotic idea....
Well, there's no politics here apart from wishing not to introduce short-term hacks that will haunt us for ever.
I can't take you seriously when you keep saying that, then pushing LD_PRELOAD.
What is the view of all this from PA upstream? I talked a lot to Lennart at LCA about this and he said system-wide pulse was a non-starter exactly for the reasons I listed.
That's partially because I convinced him so at GUADEC. It took some arguing.
Monty
On Tue, 2007-02-27 at 14:04 -0500, xiphmont@xiph.org wrote:
Heck, so uid 501 can poke the streams created by uid 500? That's a
show
stopper just because of security implications. Do you disagree?
I agree it's not acceptible in the mid/long term. However, this is already what Ubuntu and Debian do today.
Ding ding ding. We want to ship a distro that is secure by default. Seriously, this is a stop-ship thing whether you personally like it or not.
revoke is just such a .... stunningly... idiotic idea....
My gods. Do not pass start. Do not collect $200. Hint, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006
and come back when you understand the implications. Thanks.
Well, there's no politics here apart from wishing not to introduce short-term hacks that will haunt us for ever.
I can't take you seriously when you keep saying that, then pushing LD_PRELOAD.
It's because I live in this century and don't use OSS myself. Either LD_PRELOAD or some emulation daemon that forwards the stream to the right PA instance. Either is ugly because OSS is ugly.
Of course, we wouldn't enable such things by default because we don't have OSS apps in the default install. Perhaps enterprise distros that care about old crap would.
What is the view of all this from PA upstream? I talked a lot to Lennart at LCA about this and he said system-wide pulse was a non-starter exactly for the reasons I listed.
That's partially because I convinced him so at GUADEC. It took some arguing.
*plonk*
Here's a quarter, Monty. Go use it to try a modern Linux desktop.
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
My gods. Do not pass start. Do not collect $200. Hint, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006
and come back when you understand the implications. Thanks.
You're asking the world to upgrade to benefit your pet project or be left behind. The chances of that working out are not high.
It's because I live in this century and don't use OSS myself.
And yet you feel justified to dismiss it. I don't use the desktop much myself, so it must be unimportant.
Replace OSS with ALSA; the point still stands and perhaps you can identify more with it.
Say 'ESD' in a room full of Linux users five years ago, and the first thing anyone thought was 'Oh, it's that thing I have to kill so all my sounds apps will work again'. If we repeat that mistake with PA, PA will also become reviled.
Of course, we wouldn't enable such things by default because we don't have OSS apps in the default install. Perhaps enterprise distros that care about old crap would.
Fine. Do we ship any ALSA apps? I think we might.
Here's a quarter, Monty. Go use it to try a modern Linux desktop.
If we're going to take the gloves off, I can bitchslap with the best.
Monty
On Tue, 2007-02-27 at 15:01 -0500, xiphmont@xiph.org wrote:
My gods. Do not pass start. Do not collect $200. Hint, see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230006
and come back when you understand the implications. Thanks.
You're asking the world to upgrade to benefit your pet project or be
^^^
How nice.
left behind. The chances of that working out are not high.
No, we're just fixing past design mistakes to make the Linux desktop be true multi-user (again). In some circles it's called progress; looking forward and doing new exciting things. If such things happen to be useful, hey, more power to the Linux desktop.
It's because I live in this century and don't use OSS myself.
And yet you feel justified to dismiss it. I don't use the desktop much myself, so it must be unimportant.
I'm not dismissing OSS; there are, at least two mechanisms to support it; let me repeat
- LD_PRELOAD (widely used by LTSP) - emulation devices
Let me repeat again: both are ugly as hell because OSS is ugly as hell.
Whether we as a distro want to keep compat for these around in the *default* install is a separate issue and up to the Fedora project at large. I don't really care and I'm sure people who have a better idea of our user base does. It could go in a compat-oss package for all I care. For the record we have other compat* packages that you need to use antiquated interfaces.
Replace OSS with ALSA; the point still stands and perhaps you can identify more with it.
No, it's fine, apps use libasound and there's a plug-in for Pulse.
Say 'ESD' in a room full of Linux users five years ago, and the first thing anyone thought was 'Oh, it's that thing I have to kill so all my sounds apps will work again'. If we repeat that mistake with PA, PA will also become reviled.
I don't understand this. OSS compat is possible through two mechanisms already. Plus I have a lot of faith in the PA developers not to screw up.
Of course, we wouldn't enable such things by default because we don't have OSS apps in the default install. Perhaps enterprise distros that care about old crap would.
Fine. Do we ship any ALSA apps? I think we might.
No, it's fine, apps use libasound and there's a plug-in for Pulse.
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
Let me repeat again: both are ugly as hell because OSS is ugly as hell.
I'm not arguing with that. We need to support it regardless, or the march of forward progress will fail like it did last time. We're not in a situation where we can force bitter medicine on users 'for their own good', and we shouldn't try.
Whether we as a distro want to keep compat for these around in the *default* install is a separate issue and up to the Fedora project at large.
No, it is entirely the same issue. If only one application a user has been relying on daily for years breaks due to 'forward progress', that user is going to hate 'forward progress'. I am among the people who regard computers as tools: you use them to get work done. You don't use them because you love staring at glowing objects or because all the tech is just so damned nifty.
And very few things piss off a tool user like a tool breaking. Being informed it was for his own good does not make him happier ("just write to the author and tell him to fix his broken crap! We're trying to march toward the sunrise of a glorious tomorrow here!"). This is not to say that's not going to happen occasionally anyway, but to claim it's unimportant or obstructionist is ludicrous. This is not off topic. It is central to the problem of software adoption in a community that is not captive.
Say 'ESD' in a room full of Linux users five years ago, and the first thing anyone thought was 'Oh, it's that thing I have to kill so all my sounds apps will work again'. If we repeat that mistake with PA, PA will also become reviled.
I don't understand this. OSS compat is possible through two mechanisms already. Plus I have a lot of faith in the PA developers not to screw up.
Typing 'padsp {insert wrapped application here}' does not count as 'compatability'. If it did, we'd already be done and the world would be saved.
As for an emu daemon, we'd need to implement f-u-s awareness. The emu daemon is also a system daemon, and those are apparently evil these days.
Many applications of sound are more appliance-like than application-like. A session daemon is all fine and good until the applicance has its appliance disappear. The session daemon approach does not allow even the possibility of appliance-like sound applications.
And there's a simple problem of physics, Unlike X we can't just 'fix' the pop of a sound card when the device is shut off and restarted. If we go the session route, we will live with the pop forever. Think about what a sound card output stage looks like....
An earlier question still stands, and it is central: does UID == console session ID?
Monty
Hi Monty,
On 2/27/07, xiphmont@xiph.org xiphmont@xiph.org wrote:
An earlier question still stands, and it is central: does UID == console session ID?
To me, this is very much like asking "Does UID == $DISPLAY"? And the answer of course is - not in general.
Jon
On 2/27/07, William Jon McCann mccann@jhu.edu wrote:
Hi Monty,
On 2/27/07, xiphmont@xiph.org xiphmont@xiph.org wrote:
An earlier question still stands, and it is central: does UID == console session ID?
To me, this is very much like asking "Does UID == $DISPLAY"? And the answer of course is - not in general.
I am asking so that the answer is a documented-- and thought about-- instead of being a nebulous assumption. For one, it will be difficult to have true session-unique emulation support because those interfaces used /dev permissions with no concept of session, only uid and gid.
Monty
On Tue, 2007-02-27 at 15:44 -0500, xiphmont@xiph.org wrote:
On 2/27/07, William Jon McCann mccann@jhu.edu wrote:
Hi Monty,
On 2/27/07, xiphmont@xiph.org xiphmont@xiph.org wrote:
An earlier question still stands, and it is central: does UID == console session ID?
To me, this is very much like asking "Does UID == $DISPLAY"? And the answer of course is - not in general.
I am asking so that the answer is a documented-- and thought about-- instead of being a nebulous assumption. For one, it will be difficult to have true session-unique emulation support because those interfaces used /dev permissions with no concept of session, only uid and gid.
If the emu system daemon runs as root you, then /dev/dsp and friends would only need to be accessible by root assuming the emu system daemon passes the fd to the PA instances.
That's what I meant in the other mail with:
It's fine being a system daemon if it's a pure mechanism. Tell me, said emu system daemon knows the uid/pid of the opener of the device. Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered)
In order to identify the correct PA session instance you would look at $XDG_SESSION_COOKIE in the environment (/proc/pid/environ) for the caller. Or, more portable, make a D-Bus call to ConsoleKit to get this given the pid.
Of course, this means that PA needs to be changed to name it's sockets using the Session name (not the cookie!) instead of the username. But that change is easy. And for now GNOME (probably not KDE either) support multiple logins by the same user on the same box. But that's something we want to fix eventually.
Hope this helps.
David
On Tue, 2007-02-27 at 16:07 -0500, David Zeuthen wrote:
On Tue, 2007-02-27 at 15:44 -0500, xiphmont@xiph.org wrote:
On 2/27/07, William Jon McCann mccann@jhu.edu wrote:
Hi Monty,
On 2/27/07, xiphmont@xiph.org xiphmont@xiph.org wrote:
An earlier question still stands, and it is central: does UID == console session ID?
To me, this is very much like asking "Does UID == $DISPLAY"? And the answer of course is - not in general.
I am asking so that the answer is a documented-- and thought about-- instead of being a nebulous assumption. For one, it will be difficult to have true session-unique emulation support because those interfaces used /dev permissions with no concept of session, only uid and gid.
If the emu system daemon runs as root you, then /dev/dsp and friends would only need to be accessible by root assuming the emu system daemon passes the fd to the PA instances.
Eh, scrap that. We'd need to put ACL's on them anyway. The emu daemon would do additional checking though.
David
On Tue, 2007-02-27 at 15:32 -0500, xiphmont@xiph.org wrote:
[stuff why we should support OSS in the default install]
As I said, it's not my call whether the Fedora project should support this in the default install. For the record, if you want to run GTK 1.x apps you need to install compat packages. That's a decision that the Fedora project made after doing cost/benefit analysis etc. Things like 'cost' included
- including GTK 1.x meant fewer people ported to GTK 2.x - the apps we include in the distro were all migrated - size/complexity of maintenance - and things like...
If supporting OSS out of the box just works and is cheap to maintain, hey, go for it. If there's a huge cost.. then.. back to your cost/ benefit analysis.
Personally, I'd like OSS to just work, don't get me wrong it would be *nice* to have but not something that should dictate an architecture and make it *very hard* to do future stuff (running PA system-wide).
Typing 'padsp {insert wrapped application here}' does not count as 'compatability'. If it did, we'd already be done and the world would be saved.
As for an emu daemon, we'd need to implement f-u-s awareness. The emu daemon is also a system daemon, and those are apparently evil these days.
It's fine being a system daemon if it's a pure mechanism. Tell me, said emu system daemon knows the uid/pid of the opener of the device. Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered)
Many applications of sound are more appliance-like than application-like. A session daemon is all fine and good until the applicance has its appliance disappear. The session daemon approach does not allow even the possibility of appliance-like sound applications.
Either
- tell them to startup Pulse themselves; or better
- we automatically launch Pulse when needed (through libasound or the system emulation daemon)
And there's a simple problem of physics, Unlike X we can't just 'fix' the pop of a sound card when the device is shut off and restarted. If we go the session route, we will live with the pop forever. Think about what a sound card output stage looks like....
We'll have the pop whenever we want to suspend the audio hardware and we do want to do that in the default install for laptops anyway. Because saving power is very important and may in the future be a requirement to sell to governments.
Besides, your assumption that the sound card will be switched off/on during session switch (and cause a pop) is utterly wrong - the kernel driver for the hardware would of course only suspend the sound card after N seconds of no openers. Further, only few sound card drivers do this already, I can only think of the one for OLPC hardware.
An earlier question still stands, and it is central: does UID == console session ID?
Nope.
David
It's fine being a system daemon if it's a pure mechanism. Tell me, said emu system daemon knows the uid/pid of the opener of the device.
Yes.
Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered)
That's orthogonal to the argument of system pulse vs. session pulse-- but yes it could talk to pulse either way. It would not be passing an fd (it's using shared mem), but that's an implementation aside.
Many applications of sound are more appliance-like than application-like. A session daemon is all fine and good until the applicance has its appliance disappear. The session daemon approach does not allow even the possibility of appliance-like sound applications.
Either
- tell them to startup Pulse themselves; or better
- we automatically launch Pulse when needed (through libasound or the system emulation daemon)
Either would be incompatable with the desktop arrangement; you've set up a situation where serious audio software would be inherently at least partially incompatable with working on a Gnome desktop.
Or we'd have to implement both-- a system Pulse for 'appliance' applications that implements auth, etc, anyway, and a coordinated cloud of session pulses. Of course, since they're not really sharing-- one pulse can have the sound devices at a time-- the appliance pulse would lock out the others.
We'll have the pop whenever we want to suspend the audio hardware and we do want to do that in the default install for laptops anyway.
We can suspend Pulse without suspending the hardware, BTW... the kernel drivers will take care of pushing silence...
Because saving power is very important and may in the future be a requirement to sell to governments.
Sure and there are cases where we do want the full-blown suspension. Does that mean we mandate the lowest common denominator? Most people will not want the popping.
Besides, your assumption that the sound card will be switched off/on during session switch (and cause a pop) is utterly wrong - the kernel driver for the hardware would of course only suspend the sound card after N seconds of no openers.
Demonstrably incorrect.
An earlier question still stands, and it is central: does UID == console session ID?
Nope.
How do you regulate /dev access? A user logged in twice would hand both sessions full access.
Monty
On Tue, 2007-02-27 at 16:13 -0500, xiphmont@xiph.org wrote:
Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered)
That's orthogonal to the argument of system pulse vs. session pulse--
Not really. We're arguing what's best to do - either a system or session PA and this demonstrates that OSS compat has nothing to do with that.
but yes it could talk to pulse either way. It would not be passing an fd (it's using shared mem), but that's an implementation aside.
Right.
Many applications of sound are more appliance-like than application-like. A session daemon is all fine and good until the applicance has its appliance disappear. The session daemon approach does not allow even the possibility of appliance-like sound applications.
Either
- tell them to startup Pulse themselves; or better
- we automatically launch Pulse when needed (through libasound or the system emulation daemon)
Either would be incompatable with the desktop arrangement; you've set up a situation where serious audio software would be inherently at least partially incompatable with working on a Gnome desktop.
Or we'd have to implement both-- a system Pulse for 'appliance' applications that implements auth, etc, anyway, and a coordinated cloud of session pulses.
I think if you building an appliance
- it's not too much work to start another instance of PA; if this can be done on-demand (as you didn't argue it couldn't) then it's all automatic - your appliance would probably run unprivileged (See: flumotion)
Of course, since they're not really sharing-- one pulse can have the sound devices at a time-- the appliance pulse would lock out the others.
I think ideally we'd have a system-wide daemon that all per-session PA's connect to which does mixing and handling emulation devices. Perhaps, for you, that is PA (with few modules loaded) and we're talking about the same thing. Such a thing would be ConsoleKit aware, e.g. it would enforce (tweakable) policy such as muting inactive sessions.
Still, I _do_ want PA in my session so I can do all the "compiz for sound" things (settings) and, in particular, I don't want other users to be able to tweak my streams (security).
We'll have the pop whenever we want to suspend the audio hardware and we do want to do that in the default install for laptops anyway.
We can suspend Pulse without suspending the hardware, BTW... the kernel drivers will take care of pushing silence...
Yea, but the chip is powered up and eating battery as long as someone has the device file open - the kernel driver has no chance to know it's silence and it shouldn't. (actually some drivers power down parts of the chip depending on whether capture/playback device files are open.)
Because saving power is very important and may in the future be a requirement to sell to governments.
Sure and there are cases where we do want the full-blown suspension. Does that mean we mandate the lowest common denominator? Most people will not want the popping.
I think it's a user preference really. We have this thing in g-p-m to tweak this desktop-wide preference
http://people.freedesktop.org/~david/g-p-m-prefer-power-savings.png (for some reason this is not in Rawhide - I'll investigate)
(actually these are two settings; one for when running on battery that defaults to TRUE; one is for running on AC which defaults to FALSE. Which I think is sane).
but perhaps Pulse itself could offer a setting whether to use the desktop-wide setting or the user could specify a timeout.
My point being, it's a user setting. If the user says "never turn off sound card when there is silence" (by some setting) then the in-session PA just streams silence to the system-wide daemon or kernel driver.
Besides, your assumption that the sound card will be switched off/on during session switch (and cause a pop) is utterly wrong - the kernel driver for the hardware would of course only suspend the sound card after N seconds of no openers.
Demonstrably incorrect.
So I take it you can point to a kernel driver that doesn't wait N seconds. Return to dealer :-) - more seriously, you do know that runtime power management isn't really set in stone in the Linux kernel yes? Anyway, the point is that this is the behavior we want, don't you agree?
An earlier question still stands, and it is central: does UID == console session ID?
Nope.
How do you regulate /dev access?
Access in Linux is per-user/per-group and that's hard to change. The $XDG_SESSION_COOKIE thing is simply a way for a system-wide process to identify what desktop session a process belongs to. It isn't used to enforce any security whatsoever.
A user logged in twice would hand both sessions full access.
Yup.
David
On Tue, 2007-02-27 at 16:38 -0500, David Zeuthen wrote:
A user logged in twice would hand both sessions full access.
Yup.
Well actually, the answer here is: it depends. For things like multi-seat you probably assign one sound card soundA to seat1 and another sound card soundB to seat2. So if user is logged in twice at seat1 he still don't have access to soundB.
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
On Tue, 2007-02-27 at 16:38 -0500, David Zeuthen wrote:
A user logged in twice would hand both sessions full access.
Yup.
Well actually, the answer here is: it depends. For things like multi-seat you probably assign one sound card soundA to seat1 and another sound card soundB to seat2. So if user is logged in twice at seat1 he still don't have access to soundB.
I know you didn't *say* LTSP....
But seriously, how is that currently done with, say, two webcams?
Monty
On Tue, 2007-02-27 at 16:57 -0500, xiphmont@xiph.org wrote:
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
On Tue, 2007-02-27 at 16:38 -0500, David Zeuthen wrote:
A user logged in twice would hand both sessions full access.
Yup.
Well actually, the answer here is: it depends. For things like multi-seat you probably assign one sound card soundA to seat1 and another sound card soundB to seat2. So if user is logged in twice at seat1 he still don't have access to soundB.
I know you didn't *say* LTSP....
Some estimates out there put GNOME on LTSP as having double-digits market shares of all GNOME deployments. IIRC about 37%. I don't have any links to back this up right now though. It's kinda funny, you're very defensive about keeping compat etc, but seem to ignore "pet projects" like f-u-s, multi-seat and LTSP... anyway...
But seriously, how is that currently done with, say, two webcams?
ConsoleKit knows about Sessions and Seats. HAL will assign ACL's based on this. It needs a bit more work (definition of seats and what devices belongs to what seats etc.) so not going to happen for F7. There's also the X.org and Linux VT subsystem to keep in mind. But it's not really hard.
FWIW, it came up last week on GNOME's desktop-devel-list
http://mail.gnome.org/archives/desktop-devel-list/2007-February/msg00290.htm... http://mail.gnome.org/archives/desktop-devel-list/2007-February/msg00291.htm...
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
On Tue, 2007-02-27 at 16:13 -0500, xiphmont@xiph.org wrote:
Presumably this emu system daemon would pass the file descriptor to the appropriate PA instance. How about that? (I tried to ask a few times but you never really answered)
That's orthogonal to the argument of system pulse vs. session pulse--
Not really. We're arguing what's best to do - either a system or session PA and this demonstrates that OSS compat has nothing to do with that.
I meant technically orthogonal. It can be done regardless of session vs. system.
I think ideally we'd have a system-wide daemon that all per-session PA's connect to which does mixing and handling emulation devices. Perhaps, for you, that is PA (with few modules loaded) and we're talking about the same thing. Such a thing would be ConsoleKit aware, e.g. it would enforce (tweakable) policy such as muting inactive sessions.
Ah, so it boils down to a semantic argument... yes, that 'system daemon' is what I am calling Pulse Audio, in that it will have most of the actual mechanism in it.
Still, I _do_ want PA in my session so I can do all the "compiz for sound" things (settings) and, in particular, I don't want other users to be able to tweak my streams (security).
We could do it that way, the worry is the latency/complexity introduced by the sound stream having to touch too many hands/endure extra context switches before making it to the actual hardware. We are talking about, for the most part, the same conceptual abstractions, but I'm talking about them all existing in the same process space. A 'system' pulse must, at a very minimum, exhibit full session personalities/awareness to the apps.
We're not arguing at all about the end-functionality in this case.
Yea, but the chip is powered up and eating battery as long as someone has the device file open - the kernel driver has no chance to know it's silence and it shouldn't. (actually some drivers power down parts of the chip depending on whether capture/playback device files are open.)
Actually, the driver *does* know it's silence because of the way the transactions are handled by ALSA; if the device is open and no app is feeding data, ALSA can be told to supply silence (or hold last value, or an y number of things).
As for 'eating power', if it's a hundred mA, I fully agree with you. If it's 10mA, I'm less sure. If it's a mA or less, I laugh at your requirements unless it's OLPC :-)
I think it's a user preference really. We have this thing in g-p-m to tweak this desktop-wide preference
I know it's fashonable to make this a session preference, but it isn't really. This is a decision it makes more sense to give to root. But I don't care enough to argue.
but perhaps Pulse itself could offer a setting whether to use the desktop-wide setting or the user could specify a timeout.
Well, I argue for it being a system (not desktop) setting as it has to do with a system resource. But enh.
My point being, it's a user setting. If the user says "never turn off sound card when there is silence" (by some setting) then the in-session PA just streams silence to the system-wide daemon or kernel driver.
..and what happens during the transition? It depends on the settings of each user combined....?
So I take it you can point to a kernel driver that doesn't wait N seconds. Return to dealer :-)
None of the USB sound cards wait, because USB shuts them down immediately upon last transaction finishing. For other cards, it's by driver and they're not consistent.
more seriously, you do know that runtime power management isn't really set in stone in the Linux kernel yes?
I know, never was. Brand new system every three years.... My thinkpad could suspend properly in 2004 :-(
Anyway, the point is that this is the behavior we want, don't you agree?
I'd opt toward 'smoothest behavior in all cases' unless demostrated that a powered sound chip is causing measurable drain. That's not an argument against full options being available regardless.
A user logged in twice would hand both sessions full access.
Yup.
Oh, well if that's an accepted part of the design, my work is easier.
Monty
On Tue, 2007-02-27 at 16:56 -0500, xiphmont@xiph.org wrote:
I think it's a user preference really. We have this thing in g-p-m to tweak this desktop-wide preference
I know it's fashonable to make this a session preference, but it isn't really. This is a decision it makes more sense to give to root. But I don't care enough to argue.
That's the same as saying it's also root's choice what screen resolution you run your monitor at (sadly, that's partly true today - you can't make it larger until we get xrandr 1.2) or when you decide it's ok for the system to suspend. Sure, these are system resources, in a OS architecture sense, but keep in mind there's a user in front of the system. Alice and probably 95% of all users don't care about the pop. Bob (and Bob don't know anything about Linux nor what a configuration file even is) and Monty does so we give them an easy way to fix this.
..and what happens during the transition? It depends on the settings of each user combined....?
For a single seat machine it depends on the user whose session is active. For multi seat, it's more complicated.
Anyway, the point is that this is the behavior we want, don't you agree?
I'd opt toward 'smoothest behavior in all cases' unless demostrated that a powered sound chip is causing measurable drain. That's not an argument against full options being available regardless.
Every single watt counts. Ever wondered why you get less battery run-time when running Linux?
All this talk about a system-wide PulseAudio sounds interesting but from what I've seen in the Fedora repositories this is a bit from what we've got today. In particular I'm concerned about labeling streams etc. from different users and ensuring they can't interfere with each other. It would be really good with a mail going into technical details about this. Thanks.
David
On 2/27/07, David Zeuthen davidz@redhat.com wrote:
Every single watt counts. Ever wondered why you get less battery run-time when running Linux?
If we are talking about a watt. Or a milliwatt. What if we're talking about 100uWatt? Is it worth it then? Again, those USB sound devices are on the touchy side and a notebook is even more likely to be using one...
All this talk about a system-wide PulseAudio sounds interesting but from what I've seen in the Fedora repositories this is a bit from what we've got today. In particular I'm concerned about labeling streams etc. from different users and ensuring they can't interfere with each other. It would be really good with a mail going into technical details about this. Thanks.
Well, it would be on the Wiki if I actually had any edit permissions, which I don't...
Monty
xiphmont@xiph.org wrote:
Well, it would be on the Wiki if I actually had any edit permissions, which I don't...
Take a look at http://fedoraproject.org/wiki/WikiEditing for that.
Rahul
On 2/27/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
xiphmont@xiph.org wrote:
Well, it would be on the Wiki if I actually had any edit permissions, which I don't...
Take a look at http://fedoraproject.org/wiki/WikiEditing for that.
I mean, I *should* have editing access, I've supposedly been given edit access, but I don't have edit access.
Monty
xiphmont@xiph.org wrote:
On 2/27/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
xiphmont@xiph.org wrote:
Well, it would be on the Wiki if I actually had any edit permissions, which I don't...
Take a look at http://fedoraproject.org/wiki/WikiEditing for that.
I mean, I *should* have editing access, I've supposedly been given edit access, but I don't have edit access.
I see the user name Christopher Montgomery has been added to the edit group recently by Ray Strode. Your profile page is http://fedoraproject.org/wiki/ChristopherMontgomery. Can you please login with this user name and check if you are still not able to edit wiki pages?
Rahul
On 2/28/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
I see the user name Christopher Montgomery has been added to the edit group recently by Ray Strode. Your profile page is http://fedoraproject.org/wiki/ChristopherMontgomery. Can you please login with this user name and check if you are still not able to edit wiki pages?
I can't. When I attempt to recover a lost password for 'ChristopherMontgomery', the wiki sends me a mail for 'XiphMont' instead. I had assumed the system somehow internally had aliased the two.
Monty
xiphmont@xiph.org wrote:
On 2/28/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
I see the user name Christopher Montgomery has been added to the edit group recently by Ray Strode. Your profile page is http://fedoraproject.org/wiki/ChristopherMontgomery. Can you please login with this user name and check if you are still not able to edit wiki pages?
I can't. When I attempt to recover a lost password for 'ChristopherMontgomery', the wiki sends me a mail for 'XiphMont' instead. I had assumed the system somehow internally had aliased the two.
XiphMont user name has now been deleted. Hopefully it works now.
Rahul
On 2/28/07, Rahul Sundaram sundaram@fedoraproject.org wrote:
XiphMont user name has now been deleted. Hopefully it works now.
Thank you. Although I don't want to continue to cause trouble, is it possible to change it from ChristopherMontgomery? The problem is, essentially, that Christopher isn't my name, I've never used it, I've never answered to it, not even my siblings/parents use it. Aside from being on my birth certificate it has nothing to do with me. I didn't choose it for the wiki, Redhat did.
(Monty Montgomery is weird, but at least I know it's me.)
Thanks, and sorry for the hassle. Monty
On Thursday 01 March 2007 09:27:28 xiphmont@xiph.org wrote:
Thank you. Although I don't want to continue to cause trouble, is it possible to change it from ChristopherMontgomery? The problem is, essentially, that Christopher isn't my name, I've never used it, I've never answered to it, not even my siblings/parents use it. Aside from being on my birth certificate it has nothing to do with me. I didn't choose it for the wiki, Redhat did.
How did Red Hat choose this for the wiki? You're supposed to create your own wiki account...
On 3/1/07, Jesse Keating jkeating@redhat.com wrote:
On Thursday 01 March 2007 09:27:28 xiphmont@xiph.org wrote:
Thank you. Although I don't want to continue to cause trouble, is it possible to change it from ChristopherMontgomery? The problem is, essentially, that Christopher isn't my name, I've never used it, I've never answered to it, not even my siblings/parents use it. Aside from being on my birth certificate it has nothing to do with me. I didn't choose it for the wiki, Redhat did.
How did Red Hat choose this for the wiki? You're supposed to create your own wiki account...
"Yeah Well" It was there waiting for me when they put us through 'wiki training' during new-hire orientation.
Monty
On Thursday 01 March 2007 10:33:57 xiphmont@xiph.org wrote:
"Yeah Well" It was there waiting for me when they put us through 'wiki training' during new-hire orientation.
Wait. You're talking about the internal Red Hat Wiki part of our internal intranet right? The 'wiki' we've been talking about is http://fedoraproject.org/wiki/
On 3/1/07, Jesse Keating jkeating@redhat.com wrote:
On Thursday 01 March 2007 10:33:57 xiphmont@xiph.org wrote:
"Yeah Well" It was there waiting for me when they put us through 'wiki training' during new-hire orientation.
Wait. You're talking about the internal Red Hat Wiki part of our internal intranet right? The 'wiki' we've been talking about is http://fedoraproject.org/wiki/
Oh, um, duh, of course. My brain went off in the weeds here.
So how the heck did I end up with two Fedora wiki accounts.... Hmm....
Monty
David Zeuthen scripst:
Replace OSS with ALSA; the point still stands and perhaps you can identify more with it.
No, it's fine, apps use libasound and there's a plug-in for Pulse.
OK, make Ekiga work together with Rhythmbox playing in the background (both from FC6) and then tell me how fine it is.
Matěj
On 2/28/07, Matej Cepl mcepl@redhat.com wrote:
David Zeuthen scripst:
Replace OSS with ALSA; the point still stands and perhaps you can identify more with it.
No, it's fine, apps use libasound and there's a plug-in for Pulse.
OK, make Ekiga work together with Rhythmbox playing in the background (both from FC6) and then tell me how fine it is.
That's exactly the point, it does work (at least, it's supposed to. if it doesn't work, then I will *make* it work).
Monty
tis 2007-02-27 klockan 13:49 -0500 skrev David Zeuthen:
That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted.
Ok, so what are the problems with a really naive solution like this:
When a session is swapped out from a console, some system daemon revokes the ACL:s and signals the user PulseAudio daemon to give up the device. If it doesn't comply, more force will probably have to be used. (Timeouts in user interfaces suck though.)
It could be as simple as sending SIGHUP/SIGUSR1, SIGTERM and SIGKILL to whatever process is currently hogging the device. Or use D-Bus instead of SIGHUP, since that would allow for specifying exactly what devices needs to be released.
/abo
On 2/28/07, Alexander Boström abo@kth.se wrote:
tis 2007-02-27 klockan 13:49 -0500 skrev David Zeuthen:
That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted.
Ok, so what are the problems with a really naive solution like this:
When a session is swapped out from a console, some system daemon revokes the ACL:s and signals the user PulseAudio daemon to give up the device. If it doesn't comply, more force will probably have to be used. (Timeouts in user interfaces suck though.)
It could be as simple as sending SIGHUP/SIGUSR1, SIGTERM and SIGKILL to whatever process is currently hogging the device. Or use D-Bus instead of SIGHUP, since that would allow for specifying exactly what devices needs to be released.
This viloates the tenent of 'fast user switching does not lose state'. Switching to the other login should not cause, eg, Audacity which is holding an hour of unsaved editing work to crash or get killed.
Monty
ons 2007-02-28 klockan 13:55 -0500 skrev xiphmont@xiph.org:
This viloates the tenent of 'fast user switching does not lose state'. Switching to the other login should not cause, eg, Audacity which is holding an hour of unsaved editing work to crash or get killed.
It does, yes.
Then how about just sending a signal through D-Bus and hoping it isn't ignored? We'll be ridiculed for having a cooperatively multisessioning desktop though. :)
/abo
On 2/28/07, Alexander Boström abo@kth.se wrote:
ons 2007-02-28 klockan 13:55 -0500 skrev xiphmont@xiph.org:
This viloates the tenent of 'fast user switching does not lose state'. Switching to the other login should not cause, eg, Audacity which is holding an hour of unsaved editing work to crash or get killed.
It does, yes.
Then how about just sending a signal through D-Bus and hoping it isn't ignored? We'll be ridiculed for having a cooperatively multisessioning desktop though. :)
Well, the idea is that the Pulse (be it session or system) doesn't die or get killed and applications running on the desktop are generally unaware anything changed w.r.t sound-- the Pulse mutes their streams, sample and playback get zeroed. The Pulse server, of course, will be 'cooperating', but trusted system software is allowed to be cooperative without being mocked.
Monty
On Wed, 2007-02-28 at 19:41 +0100, Alexander Boström wrote:
tis 2007-02-27 klockan 13:49 -0500 skrev David Zeuthen:
That's only because PA decides to open the device directly and haven't been taught to give it up on session inactivity. That's not hard to change and it's the right thing to do *anyway* since we probably want a default policy where audio is muted from inactive sessions just like video is muted.
Ok, so what are the problems with a really naive solution like this:
When a session is swapped out from a console, some system daemon revokes the ACL:s
HAL can do this (it's a one-line change) and probably will depending on a few things. To do this, HAL listens to ConsoleKit on the system message bus.
and signals the user PulseAudio daemon to give up the device. If it doesn't comply, more force will probably have to be used. (Timeouts in user interfaces suck though.)
If PA is running in the session, it could listen to ConsoleKit on the system message bus. That's actually what I proposed.
David
Le mardi 27 février 2007 à 13:20 -0500, David Zeuthen a écrit :
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
Per-session daemons may be nice for stuff that does not require exclusive access, to manage hardware they're a disaster. I don't want to log in at midnight so my GUI recording software is authorised to access the tuner card, wireless link should not go down at user logout, power management should happen even on a mostly headless system, etc
The "modern" Linux desktop seems limited to a single-user laptop in brick mode when one logs out. Per-sessions daemons are not simple they're dumb.
On Tue, 2007-02-27 at 20:33 +0100, Nicolas Mailhot wrote:
Le mardi 27 février 2007 à 13:20 -0500, David Zeuthen a écrit :
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
Per-session daemons may be nice for stuff that does not require exclusive access, to manage hardware they're a disaster. I don't want to log in at midnight so my GUI recording software is authorised to access the tuner card, wireless link should not go down at user logout, power management should happen even on a mostly headless system, etc
I already answered your question re device permissions here
https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00713.ht...
The "modern" Linux desktop seems limited to a single-user laptop in brick mode when one logs out.
Yes, having some kind of policy agent running when no user is logged in is desirable. It has nothing to do with this discussion though.
Per-sessions daemons are not simple they're dumb.
Actually these daemons have lots of features (for example nm-applet has WPA2, VPN, secure access to user secrets) and is by far more advanced that what we had before.
We simply just need to run them when no user is logged in. Reason why this hasn't happened is that, if you didn't know, answering the question "is a user logged in?" is damn hard to do in a portable and clever way, hence ConsoleKit. Heck, system level daemons that are pure mechanisms, like HAL, now leverage this CK to do things like this
http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=d11a896c7cf1edd2d1d1e466...
Again, it has nothing to do with this discussion.
David
On Tue, 2007-02-27 at 14:41 -0500, David Zeuthen wrote:
Actually these daemons have lots of features (for example nm-applet has WPA2, VPN, secure access to user secrets) and is by far more advanced that what we had before.
We simply just need to run them when no user is logged in.
And, for the record, the reason this is super desirable is that to configure system-wide policy (e.g. when no one is logged in), we can re-use exactly the same configuration applets, e.g. for the g-p-m preference dialog you'd have a button
[ Set these settings as system wide ]
that would (possibly after auth) copy these settings to the system-wide preference area. For a single-user laptop probably this would be done by default. All this could (possibly) be useful on servers too; e.g. you could have the policy for g-v-m when no-one is logged in to automount media and share it on the local network via Avahi. Use case would be some system that have a CD with patches he needs 100 different servers to access; just pop in the disc and it's available on the network.
But now I'm drifting off-topic....
David
Le mardi 27 février 2007 à 14:41 -0500, David Zeuthen a écrit :
On Tue, 2007-02-27 at 20:33 +0100, Nicolas Mailhot wrote:
Le mardi 27 février 2007 à 13:20 -0500, David Zeuthen a écrit :
So it's like this. For *modern* Linux desktop we've been moving functionality from system-wide daemons into per-session daemons *simply* because system-wide daemons have a number of problems.
Per-session daemons may be nice for stuff that does not require exclusive access, to manage hardware they're a disaster. I don't want to log in at midnight so my GUI recording software is authorised to access the tuner card, wireless link should not go down at user logout, power management should happen even on a mostly headless system, etc
I already answered your question re device permissions here
https://www.redhat.com/archives/fedora-maintainers/2007-February/msg00713.ht...
Oh, seems this one was eaten by a spam filter
It's a bit more complex than that, a tuner won't record more than one channel at a time, so you need something between the hardware and the GUI frontends to warn some other user already booked a timespan. You know, like cups managing one system access to its printers (shock! system-wide-daemon for desktop use)
Also with DVI and friends the video part may depend on a dedicated card but the audio just use one audio input of the motherboard/audio card.
I suspect if ever the "drop hardware access to non-active sessions" stuff is implemented people will find lots of other examples where hardware access lifetime and gui session lifetime do not map (even for desktop-related tasks). Linux desktop needs are far bigger than sunray needs.
And even without taking hardware into account, mail processing (spam filtering, etc) should happen in the background without needing to keep a GUI session with a MUA running. People hate the "log in the morning, watch evo struggle with mail received in the night" syndrome. Home/SOHO desktop should be like a VCR : you schedule evenemential/periodic tasks, they just happen even when you're doing non-computer stuff, and the results are ready when you log in. You don't ever switch off the computer it goes in low-power modes as needed without manual intervention.
The only system for which it's not true is on-battery roaming laptop, which is not the general case (the laptops sales may have skyrocketed, but the bulk of home users don't roam and let their laptop always-on on the computer table of the house)
On Wed, 2007-02-28 at 07:28 +0100, Nicolas Mailhot wrote:
It's a bit more complex than that, a tuner won't record more than one channel at a time, so you need something between the hardware and the GUI frontends to warn some other user already booked a timespan. You know, like cups managing one system access to its printers (shock! system-wide-daemon for desktop use)
First I was going to say that 1) v4l devices are exclusive-openers; and 2) use O_EXCL for other kinds of devices. But then I realized you're talking about a PVR getting ready to capture a recording in the future.
So, sure, you could have some system-wide mechanism for obtaining exclusive access to the hardware that, in the process, would use revoke() to kick out other openers already hogging the device. That's something I've been wanting to put in HAL anyway (since HAL is just a mechanism); it's probably the right place since ACL is managing your permissions.
Then your conceived[1] example of a PVR appliance would just work; it would
- You're capturing video in your login session (uid=500) - you're tuned into channel 825
- Time passes
- PVR appliance decides it wants to record BSG for you. Bummer, that's on channel 62 and, rats, someone is hogging the device files
- PVR user (uid=501) calls into system-wide mechanism to get exclusive access on /dev/video0 and /dev/dsp
- System-wide mechanism removes ACL's on /dev/video0, /dev/dsp for uid 500 (it keeps ACL's for uid 501 because that's what the caller of of GetExclusiveAccess() has)
- System-wide mechanism revoke()'s access to /dev/foo, /dev/bar for uid 500. Your TV capture app in the session hopefully doesn't crash because access is revoked. Today it probably would :-)
- System-wide mechanism returns to PVR user in response to the GetExclusiveAccess() call.
- PVR appliance now have exclusive access, opens the devices and records your show
- Time passes. Disks are spinning.
- PVR appliance is done recording. It calls into ReleaseExclusiveAccess() and the system-wide mechanism reconfigures the ACL's. uid 500 can now access the devices again.
- Perhaps the video capture thing in the session for uid=500 starts showing something again.
Perhaps the kernel should have an option to open(2), say, heh, O_EXCL_AND_KICK_OTHER_OPENERES that does this but all this involves a policy decision (is uid 501 really privileged to do such a powerful operation? The kernel just don't know...) and ACL management.
I'll think a bit more about this; we need to get the interface right.. anyway, thanks for bringing this to my attention.
[1] : actually I bet the example is not so conceived
Also with DVI and friends the video part may depend on a dedicated card but the audio just use one audio input of the motherboard/audio card.
That's just device access again - I hope with Keith's and others work on that the kernel will, in the future, finally export device files (for GPU's, CRTC's and monitors [2]) so we can manage permissions on them like any other device. Then, you know, we can also run the X server as an unprivileged process. Wouldn't that be something? :-)
Lesson here is that multi-user is *hard*. Doesn't mean it's not fixable. It does require that apps adapt and use new infrastructure to learn about the environment in which they're running. That's not different from Windows or Mac OS X - many apps there don't work properly with multi-user simply because the app developer didn't write his app with this in mind.
David
[2] : Hope I got that right
On Tue, 2007-02-27 at 13:04 -0500, xiphmont@xiph.org wrote:
On 2/27/07, David Zeuthen david@fubar.dk wrote:
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Actually, it's easy. Set up a system Pulse and everyone can use sound and emulation. What needs to happen next is to implement session partitioning in Pulse, the emulation helpers and emulation daemons.
Pulse should always be running (even if it occasionally releases devices to save battery).
I'll wait for your mail about the pros and cons before getting further on this. We'd need to rethink the gnome-sound-properties if PA was to be used as a system daemon, as we wouldn't be able to easily switch outputs.
What worries me as well is the amount of work necessary to get speaker systems with more than 2 speakers (ie. stereo) working, and if it even would with PA.
I'll hold on for more details, and you can fill in the blanks for me then :)
Cheers
On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote:
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Also, keep in mind that we're going to enable accessible login (including screen readers) for gdm - I wonder if we need pulse audio running there and how it works with the alsa-pulse plug-in - will pulse-audio be activated on demand? Or will the presence of alsa-pulse just break accessible login because there's no PA instance running?
Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that.
Does esound work that way? If it doesn't, then you have the exact same problem when a user switches on the sound bling in the control-center.
If it does, then what's stopping us from using PA as a drop-in replacement for esound? It would/should work just as well as esound did before (apart from the fact that I'm told PA hogs the physical device instead of going through dmix, which means nothing works unless you have a PA sink, or use the ALSA plugin for PA).
On Tue, 2007-02-27 at 18:15 +0000, Bastien Nocera wrote:
On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote:
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Also, keep in mind that we're going to enable accessible login (including screen readers) for gdm - I wonder if we need pulse audio running there and how it works with the alsa-pulse plug-in - will pulse-audio be activated on demand? Or will the presence of alsa-pulse just break accessible login because there's no PA instance running?
Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that.
Does esound work that way? If it doesn't, then you have the exact same problem when a user switches on the sound bling in the control-center.
If it does, then what's stopping us from using PA as a drop-in replacement for esound? It would/should work just as well as esound did before (apart from the fact that I'm told PA hogs the physical device instead of going through dmix, which means nothing works unless you have a PA sink, or use the ALSA plugin for PA).
What is stopping us is that esound is not used by default and haven't for a long time. I'm all for PA but we cannot turn it on by default until it works with f-u-s. Well, we can, but then f-u-s is useless and I don't think we want to ship useless products...
David
On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote:
On Tue, 2007-02-27 at 18:15 +0000, Bastien Nocera wrote:
On Tue, 2007-02-27 at 12:23 -0500, David Zeuthen wrote:
On Tue, 2007-02-27 at 17:06 +0000, Bastien Nocera wrote:
I think this is still the best course of action for F7, given some work to 1) make PulseAudio work (as it doesn't right now for the above), 2) some integration with the GNOME sound properties so it spits out the sound events on the right device.
This needs to work with fast-user-switching and that is *hard* given that PA hogs the device (or at least used to) and most ALSA playback devices can only have a single opener (no mixing).
Also, keep in mind that we're going to enable accessible login (including screen readers) for gdm - I wonder if we need pulse audio running there and how it works with the alsa-pulse plug-in - will pulse-audio be activated on demand? Or will the presence of alsa-pulse just break accessible login because there's no PA instance running?
Thanks for looking into this - PA rocks and will make our distro so much better. But it needs to work with f-u-s or we need to decide to do pull either PA or f-u-s. Simple as that.
Does esound work that way? If it doesn't, then you have the exact same problem when a user switches on the sound bling in the control-center.
If it does, then what's stopping us from using PA as a drop-in replacement for esound? It would/should work just as well as esound did before (apart from the fact that I'm told PA hogs the physical device instead of going through dmix, which means nothing works unless you have a PA sink, or use the ALSA plugin for PA).
What is stopping us is that esound is not used by default and haven't for a long time. I'm all for PA but we cannot turn it on by default until it works with f-u-s. Well, we can, but then f-u-s is useless and I don't think we want to ship useless products...
If f-u-s breaks, right now, when the user ticks the "start up esound so I can get desktop bling", then something is broken, and needs fixing, whether or not we want to enable PA.
On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote:
What is stopping us is that esound is not used by default and haven't for a long time. I'm all for PA but we cannot turn it on by default until it works with f-u-s. Well, we can, but then f-u-s is useless and I don't think we want to ship useless products...
There's no need to paint back-and-white here. Fast user switching remains useful even if sound does not work with it. It would certainly be nicer if it all just worked, but the fact that it doesn't is no reason to exaggerate like that.
On Tue, 2007-02-27 at 13:57 -0500, Matthias Clasen wrote:
On Tue, 2007-02-27 at 13:21 -0500, David Zeuthen wrote:
What is stopping us is that esound is not used by default and haven't for a long time. I'm all for PA but we cannot turn it on by default until it works with f-u-s. Well, we can, but then f-u-s is useless and I don't think we want to ship useless products...
There's no need to paint back-and-white here. Fast user switching remains useful even if sound does not work with it. It would certainly be nicer if it all just worked, but the fact that it doesn't is no reason to exaggerate like that.
Well, what pisses me off is the fact that "per-session daemon is hard, let's just do a system-wide daemon" without realizing all the implications of this (settings, security).
I'm perfectly fine with having PA as a per-session daemon and sound on f-u-s not working if the following is on the PA roadmap
- PA giving up sound devices on silence - PA being able to give up sound devices on session switching - emulation daemon can forward fd to per-session PA daemon
or
- some kind of ultra-light system-wide daemon for arbitrating access to sound hardware for per-session PA instances
because then we can clean this up for F8 and/or an F7 update. But deciding on an architecture (system-wide PA) that I consider broken by design is just the wrong thing.
Monty, what do you think?
David
On 2/27/07, Bastien Nocera bnocera@redhat.com wrote:
And finally, the big problem, an assert trying to play back some sound: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211
I believe this is SELinux refusing to grant sufficient shared memory for Pulse to work. It doesn't happen when run as root.
Monty
On Tue, 2007-02-27 at 13:02 -0500, Christopher "Monty" Montgomery wrote:
On 2/27/07, Bastien Nocera bnocera@redhat.com wrote:
And finally, the big problem, an assert trying to play back some sound: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211
I believe this is SELinux refusing to grant sufficient shared memory for Pulse to work. It doesn't happen when run as root.
I'm using SELinux in permissive mode, and don't see any errors in /var/log/messages relating to SELinux errors (some avc denied).
On 2/27/07, Bastien Nocera bnocera@redhat.com wrote:
On Tue, 2007-02-27 at 13:02 -0500, Christopher "Monty" Montgomery wrote:
On 2/27/07, Bastien Nocera bnocera@redhat.com wrote:
And finally, the big problem, an assert trying to play back some sound: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230211
I believe this is SELinux refusing to grant sufficient shared memory for Pulse to work. It doesn't happen when run as root.
I'm using SELinux in permissive mode, and don't see any errors in /var/log/messages relating to SELinux errors (some avc denied).
Then it is likely a security policy (PAM?) refusing to grant or limiting memory access. That's not to say that Pulse shouldn't be doing a better job of trapping the error- it should.
In any case, I have seen that exact error on my own boxes, and it was due to being refused access to shared mem. Not definitive in your case, just likely.
Monty
desktop@lists.fedoraproject.org
-
Alexander Boström -
Bastien Nocera -
David Zeuthen -
David Zeuthen -
Jesse Keating -
Matej Cepl -
Matthias Clasen -
Monty Montgomery -
Nicolas Mailhot -
Pierre Ossman -
Rahul Sundaram -
William Jon McCann -
xiphmont＠xiph.org