Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Nov 26, 2009 at 04:51:25PM +0800, Markus Rechberger wrote: > Hi, > > I've been working quite a while with pulseaudio, one thing that breaks > alsa compatibility is that since PA is user based root is not allowed > to access audio. > This always worked with native Alsa even if root is not in the audio group. I have a similar question here. What should i do if I need to configure things so that sound can play as root as well as my normal user and [preferably before I log in. It is considered incorrect to run pulseaudio in system wide mode and I don't know that I want to take the performance hit anyway. If it matters I don't habitually run X. I bring that up because it seems pulseaudio interacts quite a bit with hal and the X sessions among other things and this case is not covered in the documentation exactly. I'm running this on my laptop so it's not really the embedded case that system mode is designed for but I'd like the low power and hotplug parts of pulseaudio and better mixing than dmix to try to get some more or less useful music playing out of the laptop. The laptop is currently running Fedora but help that is not distro specific would be useful because I sometimes need to fix other Linux boxes and I'm not loyal to any particular system. And I just like to learn how things work. I'm just a little bit confused about how this is supposed to work. Thanks for reading this and I'll play around with it a bit more myself and see if I can hack something up. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Nov 26, 2009 at 5:27 PM, David Csercsics wrote: > On Thu, Nov 26, 2009 at 04:51:25PM +0800, Markus Rechberger wrote: >> Hi, >> >> I've been working quite a while with pulseaudio, one thing that breaks >> alsa compatibility is that since PA is user based root is not allowed >> to access audio. >> This always worked with native Alsa even if root is not in the audio group. > > I have a similar question here. What should i do if I need to > configure things so that sound can play as root as well as my normal > user and [preferably before I log in. It is considered incorrect to run > pulseaudio in system wide mode and I don't know that I want to take the > performance hit anyway. If it matters I don't habitually run X. I bring > that up because it seems pulseaudio interacts quite a bit with hal and > the X sessions among other things and this case is not covered in the > documentation exactly. I'm running this on my laptop so it's not really > the embedded case that system mode is designed for but I'd like the low > power and hotplug parts of pulseaudio and better mixing than dmix to > try to get some more or less useful music playing out of the laptop. The > laptop is currently running Fedora but help that is not distro specific > would be useful because I sometimes need to fix other Linux boxes and > I'm not loyal to any particular system. And I just like to learn how > things work. I'm just a little bit confused about how this is supposed > to work. Thanks for reading this and I'll play around with it a bit more > myself and see if I can hack something up. As a workaround I configured it to run as daemon, but this brings up another problem.. The flash plugin is able to interfere and mute pulseaudio occasionally ... the applications (eg. mplayer) don't show up anything strange but audio is mute for it... Now someone could say it's the fault of the flash plugin (it obviously is..) but since pulseaudio tries to make things better it should try to do so for this one too... (I never had things act like this without Pulseaudio), other issues I'm still investigating ... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Nov 26, 2009 at 4:54 AM, Markus Rechberger wrote: > The flash plugin is able to interfere and mute pulseaudio occasionally > ... the applications (eg. > mplayer) don't show up anything strange but audio is mute for it... So a gotcha here is mplayer, since you mentioned it. Make sure that you're running a patched version of mplayer[0]. Can't say much about Flash, since I haven't experienced the symptom myself with it (and source not being open, etc.). -Dan [0] at least patched in the latest stable Mandriva and development Ubuntu versions, e.g., https://bugs.launchpad.net/bugs/482408 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Nov 26, 2009 at 7:48 PM, Daniel Chen wrote: > On Thu, Nov 26, 2009 at 4:54 AM, Markus Rechberger > wrote: >> The flash plugin is able to interfere and mute pulseaudio occasionally >> ... the applications (eg. >> mplayer) don't show up anything strange but audio is mute for it... > > So a gotcha here is mplayer, since you mentioned it. Make sure that > you're running a patched version of mplayer[0]. Can't say much about > Flash, since I haven't experienced the symptom myself with it (and > source not being open, etc.). > I had the same issue with basically everything also cat /dev/urandom | aplay Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 26/11/09 08:51 did gyre and gimble: Hi, I've been working quite a while with pulseaudio, one thing that breaks alsa compatibility is that since PA is user based root is not allowed to access audio. This always worked with native Alsa even if root is not in the audio group. I'm not sure if this behaviour is intended to be like that or if it can be considered as an implementation bug... If becoming root under an X11 session, try "su" rather than "su -" when becoming root (or sudo -s vs. sudo -i). If you can access the X root window then the x11 properties will be readable by the root user and the PULSE_SERVER and PULSE_COOKIE variables will be all the root user (well libpulse really) will need to be able to access the user's PA process. When becoming root under X11, the "active" session as reported by ConsoleKit, still belongs to your user, not root, and PulseAudio honours this. That's why your root user should be talking ot your user's PA daemon. If you become root but do not have access ot the user's PA daemon, then you need to ensure you are doing so in a prescribed way. e.g. if you switch to VT1, then ConsoleKit should mark your users session as no longer "active" and PA will take this hint from ConsoleKit and suspend your user's access to the sound h/w. This then leaves the h/w free for the root user to access (either directly or by spawning his own PA (which is in itself probably not recommended - root users should not really be running apps that produce sounds anyway IMO - always remember that root is dangerous and should not be used for "desktop" things - sound output is something I personally classify as a "desktop thing"). HTHs 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] Accessing audio as root
On Thu, Nov 26, 2009 at 10:31 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 26/11/09 08:51 did gyre and gimble: >> >> Hi, >> >> I've been working quite a while with pulseaudio, one thing that breaks >> alsa compatibility is that since PA is user based root is not allowed >> to access audio. >> This always worked with native Alsa even if root is not in the audio >> group. >> >> I'm not sure if this behaviour is intended to be like that or if it >> can be considered as an implementation bug... > > If becoming root under an X11 session, try "su" rather than "su -" when > becoming root (or sudo -s vs. sudo -i). If you can access the X root window > then the x11 properties will be readable by the root user and the > PULSE_SERVER and PULSE_COOKIE variables will be all the root user (well > libpulse really) will need to be able to access the user's PA process. > > When becoming root under X11, the "active" session as reported by > ConsoleKit, still belongs to your user, not root, and PulseAudio honours > this. That's why your root user should be talking ot your user's PA daemon. > > If you become root but do not have access ot the user's PA daemon, then you > need to ensure you are doing so in a prescribed way. e.g. if you switch to > VT1, then ConsoleKit should mark your users session as no longer "active" > and PA will take this hint from ConsoleKit and suspend your user's access to > the sound h/w. This then leaves the h/w free for the root user to access > (either directly or by spawning his own PA (which is in itself probably not > recommended - root users should not really be running apps that produce > sounds anyway IMO - always remember that root is dangerous and should not be > used for "desktop" things - sound output is something I personally classify > as a "desktop thing"). this pretty much sounds like a workaround, but it still breaks the behaviour of alsa without pulseaudio - thus this is no good workaround... We do reconfigure pulseaudio to run as system daemon our application by default runs as root. root should not get permission denied when he wants to play some audio... (eg. when logging in remotely as root). I don't know how the permission stuff is handled, but root should be an exception for this and be allowed by default. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 26/11/09 14:50 did gyre and gimble: I don't know how the permission stuff is handled, but root should be an exception for this and be allowed by default. The exception to the rule is not necessarily the problem (the concept itself is valid enough), but to think about this problem generally you need to understand how audio works and, more importantly, what are the underlying limitations. Firstly, PulseAudio handles software mixing for you. This is because most hardware does not support hardware mixing. This means that (at the lowest level) only one application is able to use the sound card at any given time. This clearly sucks, but obviously a software mixer solves this problem. Keeping in mind that the on a multi user system, the active user can flip around, with each real user being denied and allowed access to the audio hardware as appropriate, that it is not a nice idea to let root use the current active user's PA as this can change later, denying root the sound access by extension. So really there are only two solutions here: 1. Bypass pulse and access the audio directly. 2. Run roots very own PA process and use it. 3. Run system-wide PA. 4. Run PA on top of some lower level mixer e.g. dmix. Now all of these have major flaws and disadvantages. 1 and 2 require hardware mixing which is not all that common these days so is totally out of the question. 3. Is nasty, requiring access rules to be pushed into user administration (e.g. adding users to the pulse-access group)[0], and also breaking SHM usage in IPC which adds huge overhead. 4. Adds lots of latency and totally breaks glitch free control of the sound hardware which has huge knock on effects for power savings and other important aspects. So really the problem is not all that simple. When considering all the various things that the old approach did not allow, but pulseaudio permits, this regression is really not a major one. Like I said previously you have to ask yourself some very serious questions when you are using a root process to interact with sound anyway? Why should any root process be doing that? Root is evil and should be avoided except when absolutely necessary. Added to that, the 99% use case of "root requireing sound" is while working under X11 and your regular user becomes root (su/sudo) to display a GUI app, sound will work just fine, so this is not a problem. The other marginal cases really don't present me with a burning problem that keeps me awake at night! 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] Accessing audio as root
On Thu, Nov 26, 2009 at 11:15 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 26/11/09 14:50 did gyre and gimble: >> >> I don't know how the permission stuff is handled, but root should be >> an exception for this and >> be allowed by default. > > The exception to the rule is not necessarily the problem (the concept itself > is valid enough), but to think about this problem generally you need to > understand how audio works and, more importantly, what are the underlying > limitations. > > Firstly, PulseAudio handles software mixing for you. This is because most > hardware does not support hardware mixing. This means that (at the lowest > level) only one application is able to use the sound card at any given time. > This clearly sucks, but obviously a software mixer solves this problem. > > Keeping in mind that the on a multi user system, the active user can flip > around, with each real user being denied and allowed access to the audio > hardware as appropriate, that it is not a nice idea to let root use the > current active user's PA as this can change later, denying root the sound > access by extension. > > So really there are only two solutions here: > 1. Bypass pulse and access the audio directly. > 2. Run roots very own PA process and use it. > 3. Run system-wide PA. > 4. Run PA on top of some lower level mixer e.g. dmix. > > Now all of these have major flaws and disadvantages. 1 and 2 require > hardware mixing which is not all that common these days so is totally out of > the question. 3. Is nasty, requiring access rules to be pushed into user > administration (e.g. adding users to the pulse-access group)[0], and also > breaking SHM usage in IPC which adds huge overhead. 4. Adds lots of latency > and totally breaks glitch free control of the sound hardware which has huge > knock on effects for power savings and other important aspects. > ok this sounds like PA breaks compatibility by design here... > So really the problem is not all that simple. When considering all the > various things that the old approach did not allow, but pulseaudio permits, > this regression is really not a major one. Like I said previously you have > to ask yourself some very serious questions when you are using a root > process to interact with sound anyway? Why should any root process be doing > that? Root is evil and should be avoided except when absolutely necessary. > Added to that, the 99% use case of "root requireing sound" is while working > under X11 and your regular user becomes root (su/sudo) to display a GUI app, > sound will work just fine, so this is not a problem. The other marginal > cases really don't present me with a burning problem that keeps me awake at > night! > we could move it to kernelspace too it's a driver. please do not break the default behaviour. We already have some issues since the system structure is inconsistent across most distributions, but PA currently puts on a crown onto it. we do not necessarily run X11 on our systems either. If I'm logged in as root I'd like to have the control over the box whatever happens. So getting a permission denied from mplayer when playing audio is not a good way to go, especially since it worked with alsa and oss. So it's 2 systems which worked for years against 1 system which caused alot problems during the last year, and those 2 somewhat 'mature' systems will continue to work like that. I haven't tried other Unix based systems yet but I do imagine that other systems do work. (eg OSX definitely works as root too!) The question should not be why do you need it, instead how can it be fixed... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 26/11/09 15:32 did gyre and gimble: So really there are only two solutions here: 1. Bypass pulse and access the audio directly. 2. Run roots very own PA process and use it. 3. Run system-wide PA. 4. Run PA on top of some lower level mixer e.g. dmix. Now all of these have major flaws and disadvantages. 1 and 2 require hardware mixing which is not all that common these days so is totally out of the question. 3. Is nasty, requiring access rules to be pushed into user administration (e.g. adding users to the pulse-access group)[0], and also breaking SHM usage in IPC which adds huge overhead. 4. Adds lots of latency and totally breaks glitch free control of the sound hardware which has huge knock on effects for power savings and other important aspects. ok this sounds like PA breaks compatibility by design here... Pretty much yeah. This is simply not a use case we're focusing on. we could move it to kernelspace too it's a driver. Do you read lkml? Not going to happen. please do not break the default behaviour. Default behaviour? That's just what it's defined as... you are asking not to be *current* behaviour. To not break default behaviour is easy.. you just re-define "Default" :p we do not necessarily run X11 on our systems either. So the use case you are now worried about is a user logging in to a text console, and starting a sound producing application (which launches pulse), either putting that app in the background (or using "screen" or similar apps) or exiting that program but then acting quickly before PA dies, then becoming root and launching a second sound producing application? This is a really, really, really niche use case! All other scenarios work fine due to console kit permission grants etc. If I'm logged in as root I'd like to have the control over the box whatever happens. Sure, but like I said before if a user is using the physical hardware already, even root cannot always get magical access if it's currently blocked without killing the user process. So getting a permission denied from mplayer when playing audio is not a good way to go, especially since it worked with alsa and oss. Doesn't work with oss over alsa - first process gets dibs. I've already explained why the pure alsa dmix approach (while very clever and nice by itself) will totally break other nice things we can do with regards to power savings etc. due to the glitch free system. So while you point out a "solution" here it has a distinct cost... personally, on balance, I thing it's more than worth the cost for the very very niche use case breakage. 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] Accessing audio as root
On Fri, Nov 27, 2009 at 2:00 AM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 26/11/09 15:32 did gyre and gimble: >>> >>> So really there are only two solutions here: >>> 1. Bypass pulse and access the audio directly. >>> 2. Run roots very own PA process and use it. >>> 3. Run system-wide PA. >>> 4. Run PA on top of some lower level mixer e.g. dmix. >>> >>> Now all of these have major flaws and disadvantages. 1 and 2 require >>> hardware mixing which is not all that common these days so is totally out >>> of >>> the question. 3. Is nasty, requiring access rules to be pushed into user >>> administration (e.g. adding users to the pulse-access group)[0], and also >>> breaking SHM usage in IPC which adds huge overhead. 4. Adds lots of >>> latency >>> and totally breaks glitch free control of the sound hardware which has >>> huge >>> knock on effects for power savings and other important aspects. >>> >> >> ok this sounds like PA breaks compatibility by design here... > > Pretty much yeah. This is simply not a use case we're focusing on. > > >> we could move it to kernelspace too it's a driver. > > Do you read lkml? Not going to happen. > no, I meant our work not pulseaudio. We moved the entire video4linux and DVB framework to userspace. audio is directly handled by the driver in our case. And the driver usually runs as root. Right now we reconfigure pulseaudio with our installer to run as systemwide process in order to support root audio playback. >> please do not break the default behaviour. > > Default behaviour? That's just what it's defined as... you are asking not to > be *current* behaviour. To not break default behaviour is easy.. you just > re-define "Default" :p > >> we do not necessarily run X11 on our systems either. > > So the use case you are now worried about is a user logging in to a text > console, and starting a sound producing application (which launches pulse), > either putting that app in the background (or using "screen" or similar > apps) or exiting that program but then acting quickly before PA dies, then > becoming root and launching a second sound producing application? > > This is a really, really, really niche use case! > > All other scenarios work fine due to console kit permission grants etc. > > I think the explanation above gives you an insight about what we need actually. >> If I'm logged in as root I'd like to have the control over the box >> whatever happens. > > Sure, but like I said before if a user is using the physical hardware > already, even root cannot always get magical access if it's currently > blocked without killing the user process. > >> So getting a permission denied from mplayer when playing audio is not >> a good way to go, >> especially since it worked with alsa and oss. > > Doesn't work with oss over alsa - first process gets dibs. I've already > explained why the pure alsa dmix approach (while very clever and nice by > itself) will totally break other nice things we can do with regards to power > savings etc. due to the glitch free system. So while you point out a > "solution" here it has a distinct cost... personally, on balance, I thing > it's more than worth the cost for the very very niche use case breakage. > I'm looking for an acceptable solution. I do know that pulseaudio usually is not stable on almost all systems out there, there are cases which seem to cause problems with PA, eg starving audio.. this finally triggers a mechanism in our driver which tries to kill PA and bypass it afterwards.. Although I do think PA will become stable at some time so I'm interested in having it work a better way... we currently only use the pulseaudio simple API but the PA system reconfiguration is not what we want. How about changing the group to the PA group temporary when trying to use it as root for setting up the mapping? Question here what's the best way to determine the group of the running PA daemon? Is there something comfortable available for this or do we have to parse the proc/pid structure, using /etc/passwd, a PA API call? Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 26/11/09 18:13 did gyre and gimble: we could move it to kernelspace too it's a driver. Do you read lkml? Not going to happen. no, I meant our work not pulseaudio. Ahh right, sorry :) We moved the entire video4linux and DVB framework to userspace. audio is directly handled by the driver in our case. And the driver usually runs as root. Not sure I really follow here... As a general rule I doubt the kernel folks would want to move stuff that can be done in userspace into the kernel tho'. Right now we reconfigure pulseaudio with our installer to run as systemwide process in order to support root audio playback. I'm not really sure that is a good idea. Unless this is done on some kind of specialist distro, I'd certainly be pretty pissed of as a user if this was done behind my back. Like I say using system-wide has lots of disadvantages and is generally not supported by us upstream in any official capacity. The lack of SHM means there is a lot of data copied around (instead of being predominantly zero-copy) and the onus is moved ot the user with regards to who is allowed access (although I don't see any reason why we cannot use console-kit's active state (plus special exemption for root) under system-wide mode, thus doing away with the need for checking that users are in pulse-access group. We would also need to check the streams belonging to the users and cork them etc if that user becomes inactive. Likewise we should only let the API report back on the users own streams and not show those of other users - all in all this a quite a lot of work but it would make system-wide a whole lot less ugly IMO - although I could easily be missing some major points (although the SHM thing is very much a major point anyway AFAIK). I do know that pulseaudio usually is not stable on almost all systems out there, there are cases which seem to cause problems with PA, eg starving audio.. this finally triggers a mechanism in our driver which tries to kill PA and bypass it afterwards.. I've been using PA exclusively for about 2 years. I have to say that it really doesn't give me any problems in this regard. Some programs interact in a bad way, but most of those problems have been ironed out now. I really don't think that drivers should try and kill PA and by pass it etc. This is just ugly. If PA causes a major problem for your driver, just refuse to work when PA is running or use pasuspender or similar approaches. Either that or find out why PA is failing and help fix the problem in the right place. Adding workarounds such as this will only ever lead to problems and confusion. Problems should be fixed in the right place. we currently only use the pulseaudio simple API but the PA system reconfiguration is not what we want. Indeed, I really think that is a bad idea. I certainly wouldn't want this happening behind my back when I install a package. How about changing the group to the PA group temporary when trying to use it as root for setting up the mapping? Question here what's the best way to determine the group of the running PA daemon? Is there something comfortable available for this or do we have to parse the proc/pid structure, using /etc/passwd, a PA API call? Nah this is doomed to fail as /etc/passwd is just one user authentication mechanism of many. My users are stored in LDAP for example. This approach still requires system-wide mode and I think you should look for a solution at the user level. What is it ultimately that a user does with your software? How do they interact with it? When does it work? (e.g. when user is logged in or not). Perhaps with a bit of background here myself (and other users on the list) can come up with some ideas? 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] Accessing audio as root
On Fri, Nov 27, 2009 at 7:02 AM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 26/11/09 18:13 did gyre and gimble: we could move it to kernelspace too it's a driver. >>> >>> Do you read lkml? Not going to happen. >>> >> >> no, I meant our work not pulseaudio. > > Ahh right, sorry :) > >> We moved the entire video4linux and DVB framework to userspace. >> audio is directly handled by the driver in our case. And the driver >> usually runs as root. > > Not sure I really follow here... As a general rule I doubt the kernel folks > would want to move stuff that can be done in userspace into the kernel tho'. > >> Right now we reconfigure pulseaudio with our installer to run as >> systemwide process in order to support >> root audio playback. > > I'm not really sure that is a good idea. Unless this is done on some kind of > specialist distro, I'd certainly be pretty pissed of as a user if this was > done behind my back. Like I say using system-wide has lots of disadvantages > and is generally not supported by us upstream in any official capacity. The > lack of SHM means there is a lot of data copied around (instead of being > predominantly zero-copy) and the onus is moved ot the user with regards to > who is allowed access (although I don't see any reason why we cannot use > console-kit's active state (plus special exemption for root) under > system-wide mode, thus doing away with the need for checking that users are > in pulse-access group. We would also need to check the streams belonging to > the users and cork them etc if that user becomes inactive. Likewise we > should only let the API report back on the users own streams and not show > those of other users - all in all this a quite a lot of work but it would > make system-wide a whole lot less ugly IMO - although I could easily be > missing some major points (although the SHM thing is very much a major point > anyway AFAIK). > > >> I do know that pulseaudio usually is not stable on almost all systems out >> there, >> there are cases which seem to cause problems with PA, eg starving >> audio.. this finally >> triggers a mechanism in our driver which tries to kill PA and bypass >> it afterwards.. > > I've been using PA exclusively for about 2 years. I have to say that it > really doesn't give me any problems in this regard. Some programs interact > in a bad way, but most of those problems have been ironed out now. > I have been working with it for a year now with PA Simple and it has been unstable on most systems. An issue (as pointed out) seems to be if audio is starving occasionally the audio input comes from a live signal. > I really don't think that drivers should try and kill PA and by pass it etc. > This is just ugly. If PA causes a major problem for your driver, just refuse > to work when PA is running or use pasuspender or similar approaches. > > Either that or find out why PA is failing and help fix the problem in the > right place. > > Adding workarounds such as this will only ever lead to problems and > confusion. Problems should be fixed in the right place. > >> we currently only use the pulseaudio simple >> API but the PA system >> reconfiguration is not what we want. > > Indeed, I really think that is a bad idea. I certainly wouldn't want this > happening behind my back when I install a package. > I think you got the point here.. >> How about changing the group to the PA group temporary when trying to >> use it as root for setting up the mapping? >> Question here what's the best way to determine the group of the >> running PA daemon? >> Is there something comfortable available for this or do we have to >> parse the proc/pid structure, using /etc/passwd, >> a PA API call? > > Nah this is doomed to fail as /etc/passwd is just one user authentication > mechanism of many. My users are stored in LDAP for example. > I'm not sure how the PA daemon works right now but how about an API command for retrieving the currently running user? The PA simple lib could transparently use those returned values. > This approach still requires system-wide mode and I think you should look > for a solution at the user level. > > What is it ultimately that a user does with your software? How do they > interact with it? When does it work? (e.g. when user is logged in or not). > It works when the user is logged in or not. The device supports TV (+Audio), and just simple FM Radio. It is possible to remotely access this device (when configured to do so). We're about to release a webfrontend for it so you can tune FM radio through a website in your homenetwork (the network configuration needs to be enabled explicitly by the user). > Perhaps with a bit of background here myself (and other users on the list) > can come up with some ideas? > The driver which retrieves the raw audio samples runs as root, it just directly tries to play back those audio samples, but with pulseaudio it usually doesn't wor without reconfiguring it. (Note it works wi
Re: [pulseaudio-discuss] Accessing audio as root
This is a little bit offtopic I'm using Ubuntu 9.10 here. right now I'm experiencing that mplayer just mutes after a few seconds, when I start up pavucontrol audio starts to work again. See this is what I mean when writing about that Pulseaudio does not work correctly with most distributions (Ubuntu is known to have issues, although pulseaudio is configured to run per user, no other process is accessing pulseaudio, nothing is bypassing pulseaudio either here). Markus On Fri, Nov 27, 2009 at 1:08 PM, Markus Rechberger wrote: > On Fri, Nov 27, 2009 at 7:02 AM, Colin Guthrie wrote: >> 'Twas brillig, and Markus Rechberger at 26/11/09 18:13 did gyre and gimble: > > we could move it to kernelspace too it's a driver. Do you read lkml? Not going to happen. >>> >>> no, I meant our work not pulseaudio. >> >> Ahh right, sorry :) >> >>> We moved the entire video4linux and DVB framework to userspace. >>> audio is directly handled by the driver in our case. And the driver >>> usually runs as root. >> >> Not sure I really follow here... As a general rule I doubt the kernel folks >> would want to move stuff that can be done in userspace into the kernel tho'. >> >>> Right now we reconfigure pulseaudio with our installer to run as >>> systemwide process in order to support >>> root audio playback. >> >> I'm not really sure that is a good idea. Unless this is done on some kind of >> specialist distro, I'd certainly be pretty pissed of as a user if this was >> done behind my back. Like I say using system-wide has lots of disadvantages >> and is generally not supported by us upstream in any official capacity. The >> lack of SHM means there is a lot of data copied around (instead of being >> predominantly zero-copy) and the onus is moved ot the user with regards to >> who is allowed access (although I don't see any reason why we cannot use >> console-kit's active state (plus special exemption for root) under >> system-wide mode, thus doing away with the need for checking that users are >> in pulse-access group. We would also need to check the streams belonging to >> the users and cork them etc if that user becomes inactive. Likewise we >> should only let the API report back on the users own streams and not show >> those of other users - all in all this a quite a lot of work but it would >> make system-wide a whole lot less ugly IMO - although I could easily be >> missing some major points (although the SHM thing is very much a major point >> anyway AFAIK). >> >> >>> I do know that pulseaudio usually is not stable on almost all systems out >>> there, >>> there are cases which seem to cause problems with PA, eg starving >>> audio.. this finally >>> triggers a mechanism in our driver which tries to kill PA and bypass >>> it afterwards.. >> >> I've been using PA exclusively for about 2 years. I have to say that it >> really doesn't give me any problems in this regard. Some programs interact >> in a bad way, but most of those problems have been ironed out now. >> > > I have been working with it for a year now with PA Simple and it has > been unstable > on most systems. An issue (as pointed out) seems to be if audio is > starving occasionally > the audio input comes from a live signal. > >> I really don't think that drivers should try and kill PA and by pass it etc. >> This is just ugly. If PA causes a major problem for your driver, just refuse >> to work when PA is running or use pasuspender or similar approaches. >> >> Either that or find out why PA is failing and help fix the problem in the >> right place. >> >> Adding workarounds such as this will only ever lead to problems and >> confusion. Problems should be fixed in the right place. >> >>> we currently only use the pulseaudio simple >>> API but the PA system >>> reconfiguration is not what we want. >> >> Indeed, I really think that is a bad idea. I certainly wouldn't want this >> happening behind my back when I install a package. >> > > I think you got the point here.. > >>> How about changing the group to the PA group temporary when trying to >>> use it as root for setting up the mapping? >>> Question here what's the best way to determine the group of the >>> running PA daemon? >>> Is there something comfortable available for this or do we have to >>> parse the proc/pid structure, using /etc/passwd, >>> a PA API call? >> >> Nah this is doomed to fail as /etc/passwd is just one user authentication >> mechanism of many. My users are stored in LDAP for example. >> > > I'm not sure how the PA daemon works right now but how about an API > command for retrieving the currently running user? > The PA simple lib could transparently use those returned values. > >> This approach still requires system-wide mode and I think you should look >> for a solution at the user level. >> >> What is it ultimately that a user does with your software? How do they >> interact with it? When does it work? (e.g. when user is logged in or not). >> > > It works when the user is
Re: [pulseaudio-discuss] Accessing audio as root
pe, 2009-11-27 kello 13:08 +0800, Markus Rechberger kirjoitti: > It works when the user is logged in or not. > The device supports TV (+Audio), and just simple FM Radio. > It is possible to remotely access this device (when configured to do so). > We're about to release a webfrontend for it so you can tune FM radio > through a website in your homenetwork (the network configuration needs > to be enabled explicitly by the user). These are my thoughts based on this description (they may not make sense if there are additional details that make things more complicated): The product should provide kernel drivers that create a few devices: for digital TV you provide a DVB device, for FM radio you provide an ALSA capture device, and if the device also does analog TV, I'm not sure how that is usually handled - is it a v4l device for video and an ALSA capture device for sound? You apparently want to make sure that there are easy ways to actually use those devices, so you write some playback software that utilizes the standard DVB, v4l and ALSA interfaces that your kernel driver has provided. The user is free to use any other software instead of yours, thanks to the standard hardware interfaces. Your playback software shouldn't be tied in any way to your hardware, except for special hardware features that can't be exposed in a standard way (or if you really just don't want to make the software interoperable with other vendor's hardware). Let's consider local (non-networked) use first. In this case I don't see why your software should run as root. Provide a normal application that runs under the user that starts it. In the networked case your software needs to act as a server, and servers often are not associated with a user session. Here running as root makes sense, except that it doesn't - please run your server under a special-purpose user for security reasons. Anyway, here you're going to run into problems with PulseAudio. I think that reconfiguring PulseAudio to run in the system-wide mode makes sense, after notifying the user and offering a way to restore the configuration (I hope this is feasible). That's what I think, I'm not sure if it helps any... -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, Nov 27, 2009 at 2:25 PM, Tanu Kaskinen wrote: > pe, 2009-11-27 kello 13:08 +0800, Markus Rechberger kirjoitti: >> It works when the user is logged in or not. >> The device supports TV (+Audio), and just simple FM Radio. >> It is possible to remotely access this device (when configured to do so). >> We're about to release a webfrontend for it so you can tune FM radio >> through a website in your homenetwork (the network configuration needs >> to be enabled explicitly by the user). > > These are my thoughts based on this description (they may not make sense > if there are additional details that make things more complicated): > > The product should provide kernel drivers that create a few devices: for > digital TV you provide a DVB device, for FM radio you provide an ALSA > capture device, and if the device also does analog TV, I'm not sure how > that is usually handled - is it a v4l device for video and an ALSA > capture device for sound? > it's entirely userspace based, as a second feature please note that we are able to set up virtual devices (eg. streaming data from the network and emulating devices) So the audio input can either come from USB or from the network. > You apparently want to make sure that there are easy ways to actually > use those devices, so you write some playback software that utilizes the > standard DVB, v4l and ALSA interfaces that your kernel driver has > provided. The user is free to use any other software instead of yours, > thanks to the standard hardware interfaces. Your playback software > shouldn't be tied in any way to your hardware, except for special > hardware features that can't be exposed in a standard way (or if you > really just don't want to make the software interoperable with other > vendor's hardware). > no it's a full virtual driver, it supports existing DVB and analog TV applications, The entire framework is based in userspace. Linux multimedia support is currently quite a mess, default TV applications across all distributions mostly cannot handle audio by themself, this is why the driver takes care about it. Aside of that when someone sets up FM radio through the webinterface the daemon will run as root (either using a virtual device through the network or a physical one attached to the USB bus). > Let's consider local (non-networked) use first. In this case I don't see > why your software should run as root. Provide a normal application that > runs under the user that starts it. > > In the networked case your software needs to act as a server, and > servers often are not associated with a user session. Here running as > root makes sense, except that it doesn't - please run your server under > a special-purpose user for security reasons. Anyway, here you're going > to run into problems with PulseAudio. I think that reconfiguring > PulseAudio to run in the system-wide mode makes sense, after notifying > the user and offering a way to restore the configuration (I hope this is > feasible). > > That's what I think, I'm not sure if it helps any... > this is all just a workaround to fix something that pulseaudio breaks.. I'd really prefer to have something that works.. When temporary changing over to the PA group the memory mappings should be possible, shouldn't it? I won't get around to check this before the end of next week actually... PA could handle this in the PA simple library. The only exception that has to be made is for root and noone else.. The topic should be how to fix pulseaudio instead of how to work around the PA breakage. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, Nov 27, 2009 at 2:33 PM, Markus Rechberger wrote: > On Fri, Nov 27, 2009 at 2:25 PM, Tanu Kaskinen wrote: >> pe, 2009-11-27 kello 13:08 +0800, Markus Rechberger kirjoitti: >>> It works when the user is logged in or not. >>> The device supports TV (+Audio), and just simple FM Radio. >>> It is possible to remotely access this device (when configured to do so). >>> We're about to release a webfrontend for it so you can tune FM radio >>> through a website in your homenetwork (the network configuration needs >>> to be enabled explicitly by the user). >> >> These are my thoughts based on this description (they may not make sense >> if there are additional details that make things more complicated): >> >> The product should provide kernel drivers that create a few devices: for >> digital TV you provide a DVB device, for FM radio you provide an ALSA >> capture device, and if the device also does analog TV, I'm not sure how >> that is usually handled - is it a v4l device for video and an ALSA >> capture device for sound? >> > > it's entirely userspace based, as a second feature please note that we are > able > to set up virtual devices (eg. streaming data from the network and > emulating devices) > So the audio input can either come from USB or from the network. > http://support.sundtek.com/index.php/topic,4.0.html maybe this can give an additional insight... Markus >> You apparently want to make sure that there are easy ways to actually >> use those devices, so you write some playback software that utilizes the >> standard DVB, v4l and ALSA interfaces that your kernel driver has >> provided. The user is free to use any other software instead of yours, >> thanks to the standard hardware interfaces. Your playback software >> shouldn't be tied in any way to your hardware, except for special >> hardware features that can't be exposed in a standard way (or if you >> really just don't want to make the software interoperable with other >> vendor's hardware). >> > > no it's a full virtual driver, it supports existing DVB and analog TV > applications, > The entire framework is based in userspace. > Linux multimedia support is currently quite a mess, default TV > applications across > all distributions mostly cannot handle audio by themself, this is why the > driver > takes care about it. Aside of that when someone sets up FM radio through > the webinterface the daemon will run as root (either using a virtual > device through > the network or a physical one attached to the USB bus). > >> Let's consider local (non-networked) use first. In this case I don't see >> why your software should run as root. Provide a normal application that >> runs under the user that starts it. >> >> In the networked case your software needs to act as a server, and >> servers often are not associated with a user session. Here running as >> root makes sense, except that it doesn't - please run your server under >> a special-purpose user for security reasons. Anyway, here you're going >> to run into problems with PulseAudio. I think that reconfiguring >> PulseAudio to run in the system-wide mode makes sense, after notifying >> the user and offering a way to restore the configuration (I hope this is >> feasible). >> >> That's what I think, I'm not sure if it helps any... >> > > this is all just a workaround to fix something that pulseaudio > breaks.. I'd really > prefer to have something that works.. > When temporary changing over to the PA group the memory mappings > should be possible, > shouldn't it? I won't get around to check this before the end of next > week actually... > > PA could handle this in the PA simple library. The only exception that > has to be made > is for root and noone else.. > The topic should be how to fix pulseaudio instead of how to work > around the PA breakage. > > Markus > ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 27/11/09 05:54 did gyre and gimble: right now I'm experiencing that mplayer just mutes after a few seconds, when I start up pavucontrol audio starts to work again. See this is what I mean when writing about that Pulseaudio does not work correctly with most distributions (Ubuntu is known to have issues, although pulseaudio is configured to run per user, no other process is accessing pulseaudio, nothing is bypassing pulseaudio either here). mplayer -ao alsa? or mplayer -ao pulse? I suspect the former as we're currently debugging a problem relating to the alsa-pulse plugin shipped in alsa-plugins package. So this is in the process of being solved. 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] Accessing audio as root
On Fri, Nov 27, 2009 at 5:08 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 27/11/09 05:54 did gyre and gimble: >> >> right now I'm experiencing that mplayer just mutes after a few >> seconds, when I start up pavucontrol audio starts to work again. >> See this is what I mean when writing about that Pulseaudio does not >> work correctly with most distributions (Ubuntu is known to have >> issues, although pulseaudio is configured to run per user, no other >> process is accessing pulseaudio, nothing is bypassing pulseaudio >> either here). > > mplayer -ao alsa? or mplayer -ao pulse? I suspect the former as we're > currently debugging a problem relating to the alsa-pulse plugin shipped in > alsa-plugins package. So this is in the process of being solved. > both... after restarting the PC with alsamixer the device was muted (I haven't looked close enough before rebooting if it was muted..), maybe pavucontrol unmuted it but this doesn't explain the weird behaviour why audio worked somewhat for 1-10 seconds without running pavucontrol. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 27/11/09 06:33 did gyre and gimble: When temporary changing over to the PA group the memory mappings should be possible, shouldn't it? I won't get around to check this before the end of next week actually... To be honest I'm really not sure what you are trying to solve by moving the groups around... The SHM memory issue is simply that it doesn't work under system-wide mode. Moving groups around is nothing to do with this. System wide mode *requires* that any user wanting to output sound *must* be in the pulse-access group. This is why reconfiguring it in the background puts a massive amount of administration overhead onto the user to ensure all their users are configured in this way. In many ways, a system wide PA that properly sandboxes user's connections/streams according to username and/or other ACL based rules and had full integration with consolekit at that level could solve these issues (doing away with the pulse-access group requirement etc), but the SHM issue becomes a problem then which is quite a big issue. I'm really not qualified to comment on this, but it's not a problem unique to yourself. mpd is typically configured in a similar way and suffers the same problems. Bearing in mind that PA is typically aimed at desktop users, this really isn't a massive problem, but it's still one that crops up (and lets face it everyone is vocal when something is perceived as breaking and no one shouts praises for saving battery power and for making multidevice management work etc. etc.) 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] Accessing audio as root
On Fri, Nov 27, 2009 at 5:18 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 27/11/09 06:33 did gyre and gimble: >> >> When temporary changing over to the PA group the memory mappings >> should be possible, >> shouldn't it? I won't get around to check this before the end of next >> week actually... > > To be honest I'm really not sure what you are trying to solve by moving the > groups around... > > The SHM memory issue is simply that it doesn't work under system-wide mode. > Moving groups around is nothing to do with this. > > System wide mode *requires* that any user wanting to output sound *must* be > in the pulse-access group. This is why reconfiguring it in the background > puts a massive amount of administration overhead onto the user to ensure all > their users are configured in this way. > > > > In many ways, a system wide PA that properly sandboxes user's > connections/streams according to username and/or other ACL based rules and > had full integration with consolekit at that level could solve these issues > (doing away with the pulse-access group requirement etc), but the SHM issue > becomes a problem then which is quite a big issue. > > I'm really not qualified to comment on this, but it's not a problem unique > to yourself. mpd is typically configured in a similar way and suffers the > same problems. > > Bearing in mind that PA is typically aimed at desktop users, this really > isn't a massive problem, but it's still one that crops up (and lets face it > everyone is vocal when something is perceived as breaking and no one shouts > praises for saving battery power and for making multidevice management work > etc. etc.) > We'll have a closer look at it within the next 1-2 weeks. We also aim at desktop users but the product goes beyond that. Alot units have been shipped already and the PA issue becomes a bigger problem for us, we simply don't want to check all the distributions and different PA setups in order to get audio work just because PA is limited in that area... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 27/11/09 09:13 did gyre and gimble: On Fri, Nov 27, 2009 at 5:08 PM, Colin Guthrie wrote: 'Twas brillig, and Markus Rechberger at 27/11/09 05:54 did gyre and gimble: right now I'm experiencing that mplayer just mutes after a few seconds, when I start up pavucontrol audio starts to work again. See this is what I mean when writing about that Pulseaudio does not work correctly with most distributions (Ubuntu is known to have issues, although pulseaudio is configured to run per user, no other process is accessing pulseaudio, nothing is bypassing pulseaudio either here). mplayer -ao alsa? or mplayer -ao pulse? I suspect the former as we're currently debugging a problem relating to the alsa-pulse plugin shipped in alsa-plugins package. So this is in the process of being solved. both... after restarting the PC with alsamixer the device was muted (I haven't looked close enough before rebooting if it was muted..), maybe pavucontrol unmuted it but this doesn't explain the weird behaviour why audio worked somewhat for 1-10 seconds without running pavucontrol. Are you really talking about mute here or do you just mean the audio stops working? If ti's really muting then something is pretty bizarre. Pulse wont automatically mute anything (well module-cork-music-on-phone could cause e.g. skype to cause music applications to be muted while it's outputting sound etc.) But to actually change the mute status (either in pulse or at the alsa level). If you can supply "amixer -c0" and "pacmd ls" outputs before and after the muting problem then this may help to debug what's going on. 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] Accessing audio as root
On Fri, Nov 27, 2009 at 5:28 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 27/11/09 09:13 did gyre and gimble: >> >> On Fri, Nov 27, 2009 at 5:08 PM, Colin Guthrie >> wrote: >>> >>> 'Twas brillig, and Markus Rechberger at 27/11/09 05:54 did gyre and >>> gimble: right now I'm experiencing that mplayer just mutes after a few seconds, when I start up pavucontrol audio starts to work again. See this is what I mean when writing about that Pulseaudio does not work correctly with most distributions (Ubuntu is known to have issues, although pulseaudio is configured to run per user, no other process is accessing pulseaudio, nothing is bypassing pulseaudio either here). >>> >>> mplayer -ao alsa? or mplayer -ao pulse? I suspect the former as we're >>> currently debugging a problem relating to the alsa-pulse plugin shipped >>> in >>> alsa-plugins package. So this is in the process of being solved. >>> >> >> both... >> >> after restarting the PC with alsamixer the device was muted (I haven't >> looked >> close enough before rebooting if it was muted..), maybe pavucontrol >> unmuted it but this doesn't explain the >> weird behaviour why audio worked somewhat for 1-10 seconds without >> running pavucontrol. > > Are you really talking about mute here or do you just mean the audio stops > working? If ti's really muting then something is pretty bizarre. Pulse wont > automatically mute anything (well module-cork-music-on-phone could cause > e.g. skype to cause music applications to be muted while it's outputting > sound etc.) The first behaviour this morning was that mplayer muted after 2-10 seconds this morning The second behaviour after rebooting the PC was that audio didn't work because the alsa device was muted. I do not know if the first one is also somewhat related to the second behaviour and pavucontrol might have unmuted it this morning (after closing pavucontrol sound muted again - without changing anything in pavucontrol itself). Whereas the second behaviour is actually known that it might happen with Ubuntu 9.10 I will do some more experiments when I have some more time for it.. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 27/11/09 09:43 did gyre and gimble: The first behaviour this morning was that mplayer muted after 2-10 seconds this morning The second behaviour after rebooting the PC was that audio didn't work because the alsa device was muted. I do not know if the first one is also somewhat related to the second behaviour and pavucontrol might have unmuted it this morning (after closing pavucontrol sound muted again - without changing anything in pavucontrol itself). This is what is confusing me, pavucontrol wont unmute things by itself. It may however trigger behaviour that may sound like mute/unmute. To explain, the glitch free system, by default, sets a fairly high latency (this is for power saving purposes). pulse clients can control this, but alsa clients via the plugin cannot. When pavucontrol starts the latency is reduced so that vumeters in pavucontrol can give somewhat accurate results. It is this process that I think is triggering what you describe as mute/unmute, but what I think is probably more accurately represented as cork/uncork... i.e. mute implies that audio is sent ot the bit bucket, cork implies basically freezing audio consumption until it's ready. e.g. if you run an audio track that is a recoding of someone slowly counting from 1 to 100, does your mute actually skip any numbers or does it just wait and then carry on where it left off as you close and open pavucontrol? If so then I can see this being a problem with some apps, but for me at least mplayer is working fine with -ao pulse and -ao alsa, so this is a bit confusing that you are seeing this (if this was a fundamental problem with they way mplayer handled the timing, it would show up for both of us I'd have thought). Hence why this is a little odd. 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] Accessing audio as root
On Do, Nov 26 2009, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 26/11/09 14:50 did gyre and gimble: >> I don't know how the permission stuff is handled, but root should be >> an exception for this and >> be allowed by default. > > The exception to the rule is not necessarily the problem (the concept > itself is valid enough), but to think about this problem generally you > need to understand how audio works and, more importantly, what are the > underlying limitations. [...] > previously you have to ask yourself some very serious questions when > you are using a root process to interact with sound anyway? Why should > any root process be doing that? Root is evil and should be avoided > except when absolutely necessary. Well, but nevertheless an X session is required to allow differend user accounts to access the audio subsystem at the same time. This is a drawback for me as I'm used to do a lot of my daily work on a text console outside of a X session, so I need to run X just to share audio access between different user accounts. Furthermore, I'm a screenreader user, so I need Speech-Dispatcher running permanently under its own uid, which is started on boot. Sure I could run it under my main uid, but this would be kind of a workaround IMO. I really like Pulseaudio's features and use it on my Computer at home and on the laptop, but it is a lot less conviniend to use without a running X session than ALSA, which in particular makes sense on laptops and netbooks. Running PA as a system daemon would solve this problem, but I understand that this isn't advisable at all. It would be really cool if we could share PA between users without a running X session. Just my 2 cents. Henning ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, 26.11.09 01:27, David Csercsics (a...@shaw.ca) wrote: > > On Thu, Nov 26, 2009 at 04:51:25PM +0800, Markus Rechberger wrote: > > Hi, > > > > I've been working quite a while with pulseaudio, one thing that breaks > > alsa compatibility is that since PA is user based root is not allowed > > to access audio. > > This always worked with native Alsa even if root is not in the audio group. > > I have a similar question here. What should i do if I need to > configure things so that sound can play as root as well as my normal > user and [preferably before I log in. It is considered incorrect to run > pulseaudio in system wide mode and I don't know that I want to take the > performance hit anyway. If it matters I don't habitually run X. I bring > that up because it seems pulseaudio interacts quite a bit with hal and > the X sessions among other things and this case is not covered in the > documentation exactly. I'm running this on my laptop so it's not really > the embedded case that system mode is designed for but I'd like the low > power and hotplug parts of pulseaudio and better mixing than dmix to > try to get some more or less useful music playing out of the laptop. The > laptop is currently running Fedora but help that is not distro specific > would be useful because I sometimes need to fix other Linux boxes and > I'm not loyal to any particular system. And I just like to learn how > things work. I'm just a little bit confused about how this is supposed > to work. Thanks for reading this and I'll play around with it a bit more > myself and see if I can hack something up. Generally, it is simply wrong to play music as root. Which is why we don't really support it. There are mostly two reasons why folks might want audio as root: 1) they do the full X login as root. This is just wrong. Everyone who does this deserves having broken audio. If you want to switch to root for admin purposes, do so temporarily, using sudo or a similar tool. And certainly don't play any audio as root! 2) They want to run some system service that runs as root and which wants to play some audio. This is often misguided. If you have a system service running as root you already lost, you should run as its own system user, not root. A good example how this is fixed properly is gdm. The gdm login screen runs under its own gdm user which runs its own PA instance, and everything is good. So generally I believe playing audio back as root is just wrong. And unless someone convinces me otherwise (very unlikely) I don't plan to support it any better than we do right now. 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] Accessing audio as root
On Thu, 26.11.09 14:31, Colin Guthrie (gm...@colin.guthr.ie) wrote: > > 'Twas brillig, and Markus Rechberger at 26/11/09 08:51 did gyre and gimble: > >Hi, > > > >I've been working quite a while with pulseaudio, one thing that breaks > >alsa compatibility is that since PA is user based root is not allowed > >to access audio. > >This always worked with native Alsa even if root is not in the audio group. > > > >I'm not sure if this behaviour is intended to be like that or if it > >can be considered as an implementation bug... > > If becoming root under an X11 session, try "su" rather than "su -" > when becoming root (or sudo -s vs. sudo -i). If you can access the X > root window then the x11 properties will be readable by the root > user and the PULSE_SERVER and PULSE_COOKIE variables will be all the > root user (well libpulse really) will need to be able to access the > user's PA process. I don't see why anyone would want to have audio when changing to root for admin purposes. Playing music certainly does not fall under "admin purposes". 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] Accessing audio as root
On Fri, 27.11.09 17:30, Henning Oschwald (h.oschw...@gmx.de) wrote: > > previously you have to ask yourself some very serious questions when > > you are using a root process to interact with sound anyway? Why should > > any root process be doing that? Root is evil and should be avoided > > except when absolutely necessary. > > Well, but nevertheless an X session is required to allow differend user > accounts to access the audio subsystem at the same time. This is a > drawback for me as I'm used to do a lot of my daily work on a text > console outside of a X session, so I need to run X just to share audio > access between different user accounts. This is a bit confused. PA does indeed *not* allow multiple users simultaneous access to the same audio device. This is because we consider the sound card to be part of the user seat, the same way as the keyboard, the mouse, or the screen. If we'd allow multiple users access then they might eavesdrop into your voip calls or even record anything you say from the mic. As long as a user is active on a seat he should be the only one who has access to its devices. Now, what you are saying about the relation of X and console sessions is not true. On current distros it should not make much of a difference if you log into X or into the console. Only one instance of PA will be started and shared among all your sessions on your seat, be them X or the console. 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] Accessing audio as root
On Thu, Dec 17, 2009 at 11:04 AM, Lennart Poettering wrote: > On Fri, 27.11.09 17:30, Henning Oschwald (h.oschw...@gmx.de) wrote: > >> > previously you have to ask yourself some very serious questions when >> > you are using a root process to interact with sound anyway? Why should >> > any root process be doing that? Root is evil and should be avoided >> > except when absolutely necessary. >> >> Well, but nevertheless an X session is required to allow differend user >> accounts to access the audio subsystem at the same time. This is a >> drawback for me as I'm used to do a lot of my daily work on a text >> console outside of a X session, so I need to run X just to share audio >> access between different user accounts. > > This is a bit confused. > > PA does indeed *not* allow multiple users simultaneous access to the > same audio device. This is because we consider the sound card to be > part of the user seat, And this is the problem because it works with alsa, simply add every user you want to give audio access to the audio group and it worked. Even with OSS this worked. But PA breaks this behaviour. How about I set up an FM Radio server, there's a daemon process accessible through a website which runs either as root or as his own dedicated audio user - there we already have our use case. There are for sure ways around this (eg. skeeming the processlist for a pulseaudio process and suid over to it). But it should more act like all the other audio systems work. I can even imagine that with OSX it does not cause any issue to log in from a remote host and play some audio. A couple of years ago I used to log in on a remote PC and export XMMS to another PC for playing back audio, I can imagine that this is also not possible anymore with PA Please just fix this. > the same way as the keyboard, the mouse, or the > screen. If we'd allow multiple users access then they might eavesdrop > into your voip calls or even record anything you say from the mic. As > long as a user is active on a seat he should be the only one who has > access to its devices. > I don't think it's innovative to cut the possibilities back we had before, it should be up to the user what he wants to do and what not. Markus > Now, what you are saying about the relation of X and console sessions > is not true. On current distros it should not make much of a > difference if you log into X or into the console. Only one instance of > PA will be started and shared among all your sessions on your seat, be > them X or the console. > > 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] Accessing audio as root
'Twas brillig, and Markus Rechberger at 22/12/09 16:54 did gyre and gimble: > A couple of years ago I used to log in on a remote PC and export XMMS > to another PC for playing back audio, I can imagine that this is also > not possible anymore with PA The problem is you are expecting one thing whereas most people expect something else. If I login to a remote PC and export XMMS to another PC, I *expect* my audio to be played at the same location as the display is seen. This works perfectly with PA if you enable the TCP options in paprefs. 1. ssh machineb 2. (internally ssh will forward X11 via a tunnel and set $DISPLAY environment variable in your session on machineb - ssh is aware of X) 3. xmms 4. (as an x app, xmms will look at $DISPLAY, which will ultimately be tunneled over ssh to your local machine). 5. xmms -> play 6. PA client kicks in, looks for properties in the X root window (which belong to our initial machine), finds details of how to connect to our local machine (as we can't use an SSH tunnel as ssh is not aware of PA yet in the same way it is with X), connects and plays sound. This way I can sit at my laptop, ssh to my server in the next room, run a visual app that plays audio and both see and hear the app on my local machine. This is how most people expect remote applications to work. As an SSH users connecting to a remote machine, I'd have no right to access the remote machine's audio hardware. 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] Accessing audio as root
On Tue, Dec 22, 2009 at 10:16 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 22/12/09 16:54 did gyre and gimble: >> A couple of years ago I used to log in on a remote PC and export XMMS >> to another PC for playing back audio, I can imagine that this is also >> not possible anymore with PA > > The problem is you are expecting one thing whereas most people expect > something else. > > If I login to a remote PC and export XMMS to another PC, I *expect* my > audio to be played at the same location as the display is seen. This > works perfectly with PA if you enable the TCP options in paprefs. > > 1. ssh machineb > 2. (internally ssh will forward X11 via a tunnel and set $DISPLAY > environment variable in your session on machineb - ssh is aware of X) > 3. xmms > 4. (as an x app, xmms will look at $DISPLAY, which will ultimately be > tunneled over ssh to your local machine). > 5. xmms -> play > 6. PA client kicks in, looks for properties in the X root window (which > belong to our initial machine), finds details of how to connect to our > local machine (as we can't use an SSH tunnel as ssh is not aware of PA > yet in the same way it is with X), connects and plays sound. > > This way I can sit at my laptop, ssh to my server in the next room, run > a visual app that plays audio and both see and hear the app on my local > machine. This is how most people expect remote applications to work. > well I moreover mean that the soundsystem is not connected to my notebook but to the server. I pointed out to 2 use cases which don't work with PA now but with alsa and OSS, it won't help if you write that those are just my use cases it probably might turn out that everyone else's use case is not your use case either and drop such reports when they come up. I don't get why the entire permission thing should not work with other users even with SYSV IPC you should have the normal user/group permission levels. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Tue, 22.12.09 17:54, Markus Rechberger (mrechber...@gmail.com) wrote: > >> Well, but nevertheless an X session is required to allow differend user > >> accounts to access the audio subsystem at the same time. This is a > >> drawback for me as I'm used to do a lot of my daily work on a text > >> console outside of a X session, so I need to run X just to share audio > >> access between different user accounts. > > > > This is a bit confused. > > > > PA does indeed *not* allow multiple users simultaneous access to the > > same audio device. This is because we consider the sound card to be > > part of the user seat, > > And this is the problem because it works with alsa, simply add every > user you want to give audio access to the audio group and it worked. > Even with OSS this worked. But PA breaks this behaviour. First of all, we broke exactly nothing. You can always bypass PA and do stuff like this. Secondly, allowing access to the audio device to all users is a security hole as I tried to explain quite a few times. Allowing that means a user can evesdrop into your voip calls, he can even completely monitor whatever you say when you sit in front of your computer. You don't allow access to your kbd and screen to all users either, right? it was a security issue that has been open for a long long time that access to audio devices was not regulated the same way as acess to your kbd and screen. We fixed that. Just because something works differently than it worked before it doesn't mean it's broken. > How about I set up an FM Radio server, there's a daemon process > accessible through a website which runs either as root or as his own > dedicated audio user - there we already have our use case. If you use a server-like setup, i.e. a headless machine without local sessions, then use system mode of PA. (or bypass PA) > I can even imagine that with OSX it does not cause any issue to log in > from a remote host and play some audio. Actually OSX does exactly the same thing when you switch between sessions: it stops output from one session and enables output on the other. Mentioning OSX as an example here is really something that can only backfire... Also, as Colin pointed out SSH logins certainly want audio output on the terminal side, not the server side. > Please just fix this. There is nothing to "fix". > > the same way as the keyboard, the mouse, or the > > screen. If we'd allow multiple users access then they might eavesdrop > > into your voip calls or even record anything you say from the mic. As > > long as a user is active on a seat he should be the only one who has > > access to its devices. > > > > I don't think it's innovative to cut the possibilities back we had > before, it should be up to the user what he wants to do and what not. Right. It is innovative to carry on with the brokeness we always had just because we always had it and not because we would ever think about the brokeness and fix it? Is that what you think? Also, the same discussion we already had 2 years ago on fedora-devel and other mailing lists. Kinda pointless bringing this up again and again and 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] Accessing audio as root
On Wed, Dec 23, 2009 at 12:57 PM, Lennart Poettering wrote: > On Tue, 22.12.09 17:54, Markus Rechberger (mrechber...@gmail.com) wrote: > >> >> Well, but nevertheless an X session is required to allow differend user >> >> accounts to access the audio subsystem at the same time. This is a >> >> drawback for me as I'm used to do a lot of my daily work on a text >> >> console outside of a X session, so I need to run X just to share audio >> >> access between different user accounts. >> > >> > This is a bit confused. >> > >> > PA does indeed *not* allow multiple users simultaneous access to the >> > same audio device. This is because we consider the sound card to be >> > part of the user seat, >> >> And this is the problem because it works with alsa, simply add every >> user you want to give audio access to the audio group and it worked. >> Even with OSS this worked. But PA breaks this behaviour. > > First of all, we broke exactly nothing. You can always bypass PA and do > stuff like this. > > Secondly, allowing access to the audio device to all users is a > security hole as I tried to explain quite a few times. Allowing that > means a user can evesdrop into your voip calls, he can even completely > monitor whatever you say when you sit in front of your computer. You > don't allow access to your kbd and screen to all users either, > right? it was a security issue that has been open for a long long time > that access to audio devices was not regulated the same way as acess > to your kbd and screen. We fixed that. Just because something works > differently than it worked before it doesn't mean it's broken. > >> How about I set up an FM Radio server, there's a daemon process >> accessible through a website which runs either as root or as his own >> dedicated audio user - there we already have our use case. > > If you use a server-like setup, i.e. a headless machine without local > sessions, then use system mode of PA. (or bypass PA) > >> I can even imagine that with OSX it does not cause any issue to log in >> from a remote host and play some audio. > > Actually OSX does exactly the same thing when you switch between > sessions: it stops output from one session and enables output on the > other. Mentioning OSX as an example here is really something that > can only backfire... > > Also, as Colin pointed out SSH logins certainly want audio output on > the terminal side, not the server side. > >> Please just fix this. > > There is nothing to "fix". > >> > the same way as the keyboard, the mouse, or the >> > screen. If we'd allow multiple users access then they might eavesdrop >> > into your voip calls or even record anything you say from the mic. As >> > long as a user is active on a seat he should be the only one who has >> > access to its devices. >> > >> >> I don't think it's innovative to cut the possibilities back we had >> before, it should be up to the user what he wants to do and what not. > > Right. It is innovative to carry on with the brokeness we always had > just because we always had it and not because we would ever think > about the brokeness and fix it? Is that what you think? > Right, we had /etc/group for setting up the permissions pulseaudio breaks this behaviour even with the Alsa compat library. > Also, the same discussion we already had 2 years ago on fedora-devel > and other mailing lists. Kinda pointless bringing this up again and > again and again. > Sorry this behaviour is just broken, Pulseaudio should not be part of any distribution until a certain level of compatibility is reached. compiz is optional it's easily possible to enable or disable it. The recommendation to use system mode is also a failure, why should someone reconfigure the entire audio system on a distribution? We have deployed alot devices which depend on audio nowadays at certain b2b customers, guess how many are using pulseaudio? -- exactly noone. After talking to engineers everyone feels like PA is just a pain, and by forcing your ideas which break the default behaviour this situation will not improve. I'd rather like to see a clear statement why it is currently not working, so someone can get onto that topic and fix it. If you want to block it for other users add a configuration option for it but again don't break the default behaviour Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 1:16 PM, Markus Rechberger wrote: > On Wed, Dec 23, 2009 at 12:57 PM, Lennart Poettering > wrote: >> On Tue, 22.12.09 17:54, Markus Rechberger (mrechber...@gmail.com) wrote: >> >>> >> Well, but nevertheless an X session is required to allow differend user >>> >> accounts to access the audio subsystem at the same time. This is a >>> >> drawback for me as I'm used to do a lot of my daily work on a text >>> >> console outside of a X session, so I need to run X just to share audio >>> >> access between different user accounts. >>> > >>> > This is a bit confused. >>> > >>> > PA does indeed *not* allow multiple users simultaneous access to the >>> > same audio device. This is because we consider the sound card to be >>> > part of the user seat, >>> >>> And this is the problem because it works with alsa, simply add every >>> user you want to give audio access to the audio group and it worked. >>> Even with OSS this worked. But PA breaks this behaviour. >> >> First of all, we broke exactly nothing. You can always bypass PA and do >> stuff like this. >> >> Secondly, allowing access to the audio device to all users is a >> security hole as I tried to explain quite a few times. Allowing that >> means a user can evesdrop into your voip calls, he can even completely >> monitor whatever you say when you sit in front of your computer. You >> don't allow access to your kbd and screen to all users either, >> right? it was a security issue that has been open for a long long time >> that access to audio devices was not regulated the same way as acess >> to your kbd and screen. We fixed that. Just because something works >> differently than it worked before it doesn't mean it's broken. >> >>> How about I set up an FM Radio server, there's a daemon process >>> accessible through a website which runs either as root or as his own >>> dedicated audio user - there we already have our use case. >> >> If you use a server-like setup, i.e. a headless machine without local >> sessions, then use system mode of PA. (or bypass PA) >> >>> I can even imagine that with OSX it does not cause any issue to log in >>> from a remote host and play some audio. >> >> Actually OSX does exactly the same thing when you switch between >> sessions: it stops output from one session and enables output on the >> other. Mentioning OSX as an example here is really something that >> can only backfire... >> >> Also, as Colin pointed out SSH logins certainly want audio output on >> the terminal side, not the server side. >> >>> Please just fix this. >> >> There is nothing to "fix". >> >>> > the same way as the keyboard, the mouse, or the >>> > screen. If we'd allow multiple users access then they might eavesdrop >>> > into your voip calls or even record anything you say from the mic. As >>> > long as a user is active on a seat he should be the only one who has >>> > access to its devices. >>> > >>> >>> I don't think it's innovative to cut the possibilities back we had >>> before, it should be up to the user what he wants to do and what not. >> >> Right. It is innovative to carry on with the brokeness we always had >> just because we always had it and not because we would ever think >> about the brokeness and fix it? Is that what you think? >> > > Right, we had /etc/group for setting up the permissions pulseaudio breaks this > behaviour even with the Alsa compat library. > >> Also, the same discussion we already had 2 years ago on fedora-devel >> and other mailing lists. Kinda pointless bringing this up again and >> again and again. >> > > Sorry this behaviour is just broken, Pulseaudio should not be part of > any distribution > until a certain level of compatibility is reached. > compiz is optional it's easily possible to enable or disable it. > > The recommendation to use system mode is also a failure, why should > someone reconfigure > the entire audio system on a distribution? > > We have deployed alot devices which depend on audio nowadays at > certain b2b customers, > guess how many are using pulseaudio? -- exactly noone. After talking > to engineers everyone > feels like PA is just a pain, and by forcing your ideas which break > the default behaviour > this situation will not improve. > > I'd rather like to see a clear statement why it is currently not > working, so someone can get > onto that topic and fix it. If you want to block it for other users > add a configuration option for it > but again don't break the default behaviour > Just to add, we do not depend on such changes anymore since we suid over to the current running pulseaudio user. But to add some more usecases skeem freshmeat.net and write up a list of how many audio projects you are breaking (because there are quite a few ones who run as daemon). Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, 23.12.09 13:16, Markus Rechberger (mrechber...@gmail.com) wrote: > > Right. It is innovative to carry on with the brokeness we always had > > just because we always had it and not because we would ever think > > about the brokeness and fix it? Is that what you think? > > Right, we had /etc/group for setting up the permissions pulseaudio breaks this > behaviour even with the Alsa compat library. Group-based access control is too limited for controlling access to seats in a multi-session environment. That's why we have extended this with mechanisms like ConsoleKit and PolicyKit. > Sorry this behaviour is just broken, Pulseaudio should not be part > of any distribution until a certain level of compatibility is > reached. compiz is optional it's easily possible to enable or > disable it. I guess we have to agree to disagree here. ConsoleKit (which is at the core of the multi-session support on our desktops now, including in PA) has been designed 3 years ago and pushed ino all distributions. It's the wrong time to whine about that now, and to me. If you think the whole CK design is an abomination then you are welcome to, but I'd prfer if you'd take that complains somewhere else. > The recommendation to use system mode is also a failure, why should > someone reconfigure the entire audio system on a distribution? If you run things headless/in a server you have to configure things. Surprise surprise... Also, let me point out that dmix does not support simultaneous output of streams from multiple users simultaneously either by default, for security reasons. You can enable that, but you have to configure that manually and it comes with a big yellow warning sign. This means that PA and ALSA dmix are really not that different in this respect. PA will make use of audio devices it has access to. ALSA dmix can do the same. As long as one user accesses a PA device it is blocked for all other users, which is very much like with ALSA dmix. The only difference is that on ALSA dmix after the user stopped using the device it is immediately accessible to othre users again, while in PA there is a 1s timeout. Not that big a difference. I'd prefer if you'd get your facts right before you start whining. > We have deployed alot devices which depend on audio nowadays at > certain b2b customers, guess how many are using pulseaudio? -- > exactly noone. After talking to engineers everyone feels like PA is > just a pain, and by forcing your ideas which break the default > behaviour this situation will not improve. I dont force anything. It's Free Software. Take it or leave it. If you don't like it then you are entitled to that, but I find it kinda annoying if you then whine on our mailing lists, and start demanding things. That's not how it works. I am interested in constructive feedback but not at all being accused of "forcing". And if we disagree on something then please accept that. I have explained why we do things the way we do. And unless you have a better approach and some code to show I am pretty good at simply going on with what I do. > I'd rather like to see a clear statement why it is currently not > working, so someone can get onto that topic and fix it. If you want > to block it for other users add a configuration option for it but > again don't break the default behaviour Did you read any of the emails I wrote in this thread? if not, try it! 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] Accessing audio as root
Hello list, Just my thoughts on this problem: 1. pulseaudio is now the prefered audiooutput system in most distros. It brings great new features which are useful at all. I like the feature mooving streams from one audiodevice to another. This makes using of headset comfortable and is realy useful. 2. many applications are now writing native pulse drivers. They will stop writing alsa drivers at a time we don't know. This will happen if pulseaudio is more stable. I have two use case where pulseaudio makes thing not better: 1. Accessibility You all know of the outstanding latency problems (which are now fixed using the simple pulse api) and adjusting the pa_buffer_att.*. A speechserver shouldn't run as user because some times it's useful to read some boot messages. Or are you turning on your monitor after login :-)? Unfortunately you are always writing that running pa as systemservice will not supported at all and should be avoided. The distributions are integrating pa this way and don't care about console users. 2. When I decide to run some daemons like asterisk or mpd etc with other uids this is a problem for pulseaudio. The Problem can be summarized in one sentence: Pulseaudio currently breaks multiuser systems and is only useful for one-user-desktop. Running more pulse servers at a time can work but is difficult for setup. Regards Halim @Lennart DMIX is enabled in alsa since 2.6.16 and works user independend. I can run my speechserver with uid speechd and run mplayer on my halim useraccount at the same time. an alsa application which uses directly the hw0,0 device will block dmix. When apps use alsa:default all works fine over dmix. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 1:49 PM, Lennart Poettering wrote: > On Wed, 23.12.09 13:16, Markus Rechberger (mrechber...@gmail.com) wrote: > >> > Right. It is innovative to carry on with the brokeness we always had >> > just because we always had it and not because we would ever think >> > about the brokeness and fix it? Is that what you think? >> >> Right, we had /etc/group for setting up the permissions pulseaudio breaks >> this >> behaviour even with the Alsa compat library. > > Group-based access control is too limited for controlling access to > seats in a multi-session environment. That's why we have extended > this with mechanisms like ConsoleKit and PolicyKit. > >> Sorry this behaviour is just broken, Pulseaudio should not be part >> of any distribution until a certain level of compatibility is >> reached. compiz is optional it's easily possible to enable or >> disable it. > > I guess we have to agree to disagree here. > > ConsoleKit (which is at the core of the multi-session support on our > desktops now, including in PA) has been designed 3 years ago and > pushed ino all distributions. It's the wrong time to whine about that > now, and to me. If you think the whole CK design is an abomination > then you are welcome to, but I'd prfer if you'd take that complains > somewhere else. > >> The recommendation to use system mode is also a failure, why should >> someone reconfigure the entire audio system on a distribution? > > If you run things headless/in a server you have to configure > things. Surprise surprise... > > Also, let me point out that dmix does not support simultaneous output > of streams from multiple users simultaneously either by default, for > security reasons. You can enable that, but you have to configure that > manually and it comes with a big yellow warning sign. This means that > PA and ALSA dmix are really not that different in this respect. PA > will make use of audio devices it has access to. ALSA dmix can do the > same. As long as one user accesses a PA device it is blocked for all > other users, which is very much like with ALSA dmix. The only > difference is that on ALSA dmix after the user stopped using the > device it is immediately accessible to othre users again, while in PA > there is a 1s timeout. Not that big a difference. > > I'd prefer if you'd get your facts right before you start whining. > >> We have deployed alot devices which depend on audio nowadays at >> certain b2b customers, guess how many are using pulseaudio? -- >> exactly noone. After talking to engineers everyone feels like PA is >> just a pain, and by forcing your ideas which break the default >> behaviour this situation will not improve. > > I dont force anything. It's Free Software. Take it or leave it. If you > don't like it then you are entitled to that, but I find it kinda > annoying if you then whine on our mailing lists, and start demanding > things. That's not how it works. I am interested in constructive > feedback but not at all being accused of "forcing". And if we disagree > on something then please accept that. I have explained why we do > things the way we do. And unless you have a better approach and some > code to show I am pretty good at simply going on with what I do. > >> I'd rather like to see a clear statement why it is currently not >> working, so someone can get onto that topic and fix it. If you want >> to block it for other users add a configuration option for it but >> again don't break the default behaviour > > Did you read any of the emails I wrote in this thread? > > if not, try it! > You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, 23.12.09 14:45, Markus Rechberger (mrechber...@gmail.com) wrote: > You're certainly good at ignoring bugreports your way, instead of > finding solutions to fix it up. I you feel that we dont give a bug report the attention you believe it should get then hey, nothing stops you from doing some work yourself and preparing a patch! It's Free Software and we live from contributions! If a patch is good and makes sense I am happy to merge it. 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] Accessing audio as root
'Twas brillig, and Halim Sahin at 23/12/09 13:24 did gyre and gimble: > The Problem can be summarized in one sentence: > Pulseaudio currently breaks multiuser systems and is only useful for > one-user-desktop. Actually no, the exact opposite. PA works very well for multi user desktops. The vast majority of systems out there have one screen, one keyboard and one mouse. If you have multiple users and want to switch between them PA facilitates this perfectly (in a way that simply does not work with current ALSA and it's implementations. Simply switch user (using your DEs tools for this - typically by clicking Log Out and selecting "Switch User" or similar. This starts a new X server and allows another user to login in. This second user will now get access to the sound device while the previous user is locked out (but in a nice way) from producing sound). When you switch back and forth between your users (typically ctrl+alt+F7 or F8) the permissions to use the sound device follow which user is active and sound will start and stop appropriately. This is exactly how it should be and PA facilitates this. What you are complaining about is the fact that multiple users cannot use the sound hardware *at the same time* but this is really not how things should work for all the reasons listed on this thread already. It's not how it's done in Windows and it's not how it's done on OSX. We have parity with the current OSX and Windows implementations with PA in this regard. > Running more pulse servers at a time can work but is difficult for > setup. No it's not. It's the standard out of the box setup. Each user who logs in will get their own PA server automatically via XDG autostart .desktop files or PA autospawning. 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] Accessing audio as root
'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: > You're certainly good at ignoring bugreports your way, instead of > finding solutions > to fix it up. Can you give links to these bug reports please? 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] Accessing audio as root
Hi Col, 1. I gave you some examples what doesn't work as expected. How should I run my text-to-speech server before login to have audiooutput for reading the login screen? 2. Running daemons worked well under alsa (see my previous post). I am using every day this setup. Speechd runs with uid speech-dispatcher and I can also play sound as user halim. Please don't tell us that this isn't or wasn't possible. Please try to understand the problem and help if you can. I like pa and it's great new features. But it introduced problems wich should be fixed. Your given examples are related to x-sessions. Go one step back. gdm starts and the screenreader->speech-server (before login). If pulseaudio starts at this time, it would use gdm uid. In this case the audiocard can't be used by another pulseaudio after successful login. Please correct me when Iam wrong. Greetings Halim ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: >> You're certainly good at ignoring bugreports your way, instead of >> finding solutions >> to fix it up. > > Can you give links to these bug reports please? > read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Halim Sahin at 23/12/09 14:26 did gyre and gimble: > Hi Col, > 1. I gave you some examples what doesn't work as expected. > How should I run my text-to-speech server before login to have > audiooutput for reading the login screen? GDM runs under the gdm user and starts it's own PulseAudio process. This can be easily used to do the reading of the login screen. I'm not familiar with how screen readers work but that software should also be launched as the gdm user. When a real user logs in, gdm's PA and screenreader services will die or be suspended and the real user's PA and screenreader service takes over. > 2. Running daemons worked well under alsa (see my previous post). > I am using every day this setup. > Speechd runs with uid speech-dispatcher and I can also play sound as > user halim. I don't see any reason why speech-dispatcher needs to run as it's own user. Why not just run it as the user who is actually using it? At the end of the day the fact that a uid "speech-dispatcher" can access a users' sound is disturbing. If that user is compromised they can evesdrop on your user which is not very nice. > But it introduced problems wich should be fixed. I agree it has introduced problems for certain applications but just because something has changed, it doesn't mean that PA needs to support an obsolete, weird or insecure way of working that was permitted in the past. > Your given examples are related to x-sessions. > Go one step back. > gdm starts and the screenreader->speech-server (before login). > If pulseaudio starts at this time, it would use gdm uid. This is indeed what happens. > In this case the audiocard can't be used by another pulseaudio after > successful login. Yes it can. After login the gdm user is no longer permitted access to the audio devices and the logging in user take over control, starts their own PA etc. It all works nicely. Hope this helps. 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] Accessing audio as root
'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: > On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie wrote: >> 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: >>> You're certainly good at ignoring bugreports your way, instead of >>> finding solutions >>> to fix it up. >> >> Can you give links to these bug reports please? >> > > read up my use case and read up Halim's use case, have a look at > freshmeat.net how many projects are broken > because of pulseaudio. My advice is to make your way optional, add a > configuration option which provides > a compatibility mode. You want to improve audio with linux? then please do so. > You guys spent alot time on everything already and something like that > should not be a showstopper. So no actual bug reports then? 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] Accessing audio as root
On Thu, Dec 24, 2009 at 1:29 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: >> On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie wrote: >>> 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: You're certainly good at ignoring bugreports your way, instead of finding solutions to fix it up. >>> >>> Can you give links to these bug reports please? >>> >> >> read up my use case and read up Halim's use case, have a look at >> freshmeat.net how many projects are broken >> because of pulseaudio. My advice is to make your way optional, add a >> configuration option which provides >> a compatibility mode. You want to improve audio with linux? then please do >> so. >> You guys spent alot time on everything already and something like that >> should not be a showstopper. > > So no actual bug reports then? > Heh. I think the issue is resolved. apt-get remove pulseaudio is the preferred way to get audio work again. I don't see the reason why someone should use a faulty audio system. Alsa is working well enough for most applications, for the rest Windows and OSX have to be used. Merry Christmas, Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 24/12/09 12:43 did gyre and gimble: > On Thu, Dec 24, 2009 at 1:29 PM, Colin Guthrie wrote: >> 'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: >>> On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie wrote: 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and gimble: > You're certainly good at ignoring bugreports your way, instead of > finding solutions > to fix it up. Can you give links to these bug reports please? >>> >>> read up my use case and read up Halim's use case, have a look at >>> freshmeat.net how many projects are broken >>> because of pulseaudio. My advice is to make your way optional, add a >>> configuration option which provides >>> a compatibility mode. You want to improve audio with linux? then please do >>> so. >>> You guys spent alot time on everything already and something like that >>> should not be a showstopper. >> >> So no actual bug reports then? >> > > Heh. I think the issue is resolved. > apt-get remove pulseaudio is the preferred way to get audio work again. > I don't see the reason why someone should use a faulty audio system. > Alsa is working well enough for most applications, for the rest > Windows and OSX have to be used. Haha, sure whatever works for you. All I'm saying is do you expect us to trawl the internet and dig up problems without any kind of technical detail or debug info attached to them or do you think we should concentrate on answering and dealing with problems in a prescribed and constructive way - e.g. via our BTS. Honestly, give us solid bug reports and we'll attempt to fix the problems reported, but don't come here spreading FUD and talking bullshit throwing accusations without backing them up with anything other than heresay. What I want for Christmas is BUG REPORTS with proper debug information and trigger cases. Don't report a bug, don't see a fix... shock of the decade. 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] Accessing audio as root
On Thu, Dec 24, 2009 at 2:50 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 24/12/09 12:43 did gyre and gimble: >> On Thu, Dec 24, 2009 at 1:29 PM, Colin Guthrie wrote: >>> 'Twas brillig, and Markus Rechberger at 23/12/09 14:35 did gyre and gimble: On Wed, Dec 23, 2009 at 3:14 PM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 23/12/09 13:45 did gyre and > gimble: >> You're certainly good at ignoring bugreports your way, instead of >> finding solutions >> to fix it up. > > Can you give links to these bug reports please? > read up my use case and read up Halim's use case, have a look at freshmeat.net how many projects are broken because of pulseaudio. My advice is to make your way optional, add a configuration option which provides a compatibility mode. You want to improve audio with linux? then please do so. You guys spent alot time on everything already and something like that should not be a showstopper. >>> >>> So no actual bug reports then? >>> >> >> Heh. I think the issue is resolved. >> apt-get remove pulseaudio is the preferred way to get audio work again. >> I don't see the reason why someone should use a faulty audio system. >> Alsa is working well enough for most applications, for the rest >> Windows and OSX have to be used. > > Haha, sure whatever works for you. > > All I'm saying is do you expect us to trawl the internet and dig up > problems without any kind of technical detail or debug info attached to > them or do you think we should concentrate on answering and dealing with > problems in a prescribed and constructive way - e.g. via our BTS. > > Honestly, give us solid bug reports and we'll attempt to fix the > problems reported, but don't come here spreading FUD and talking > bullshit throwing accusations without backing them up with anything > other than heresay. What I want for Christmas is BUG REPORTS with proper > debug information and trigger cases. I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. People might have had an idea back then when they allowed multiple users to access the audio system. The authorization is normally handled by /etc/group, there I can clearly define who is allowed to access audio and who not. You define this behavior as a bug just because you don't seem to understand how the audio system worked before pulseaudio came up - definitely a good way to start. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: > I think it's pretty clear what the problem is. > PA does not support multiple users on one system.. > I told you if you intend to replace the existing audio system and > build up compatibility layers > add try to do it right. But for you "right" === "the exact same way it used to work". Doing it "right" for most people === "thinking about the problem and solving it in a secure manner" Just because something is no longer identical to how it worked before does not mean it's "wrong". > People might have had an idea back then when > they allowed multiple > users to access the audio system. The authorization is normally > handled by /etc/group, there > I can clearly define who is allowed to access audio and who not. Wrong. The authorisation is normally handled by Console Kit and UDEV applying ACLs correct at the appropriate times for the appropriate users. Using groups is old and unmanageable from a policy perspective. > You define this behavior as a bug just because you don't seem to > understand how the audio system > worked before pulseaudio came up - definitely a good way to start. How something used to work and how it should work are two completely different things. Lennart and others have posted perfectly clear explanations of why the old way was broken and insecure. We've fixed that problem now. Yay! Please either argue against these previous comments or accept them and move on. Saying the same thing over and over without addressing the points people raise is both rather rude and pointless. 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] Accessing audio as root
On Wed, 23.12.09 15:26, Halim Sahin (halim.sa...@freenet.de) wrote: > > Hi Col, > 1. I gave you some examples what doesn't work as expected. > How should I run my text-to-speech server before login to have > audiooutput for reading the login screen? On Fedora at least the screenreader runs as normal process in the gdm pseudo-session which also happens to run a PA instance. So everything should be fine here, and I am quite sure this is not only done on Fedora this way but all other distributions that use a current version of gdm. Of course, if you use KDE things might be different... > 2. Running daemons worked well under alsa (see my previous post). > I am using every day this setup. Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and as such everything you could do with ALSA before stays available with PA too. However input output deamons should definitely be part of the user session. That is true for PA itself AND any kind of speech daemon and suchlike. 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] Accessing audio as root
On Thu, 24.12.09 13:43, Markus Rechberger (mrechber...@gmail.com) wrote: > Heh. I think the issue is resolved. > apt-get remove pulseaudio is the preferred way to get audio work again. > I don't see the reason why someone should use a faulty audio system. > Alsa is working well enough for most applications, for the rest > Windows and OSX have to be used. Great idea! Especially since both MacOS and Windows also limit audio playback to the current active session. It's some amazing logic that you find redemption in two OSes that expose exactly the same behaviour as you hate so much about PA/CK. 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] Accessing audio as root
On Thu, 24.12.09 15:02, Markus Rechberger (mrechber...@gmail.com) wrote: > > All I'm saying is do you expect us to trawl the internet and dig up > > problems without any kind of technical detail or debug info attached to > > them or do you think we should concentrate on answering and dealing with > > problems in a prescribed and constructive way - e.g. via our BTS. > > > > Honestly, give us solid bug reports and we'll attempt to fix the > > problems reported, but don't come here spreading FUD and talking > > bullshit throwing accusations without backing them up with anything > > other than heresay. What I want for Christmas is BUG REPORTS with proper > > debug information and trigger cases. > > I think it's pretty clear what the problem is. > PA does not support multiple users on one system.. I'd prefer if you'd stop repeating this nonsense, which is simply not true as I already pointed out a couple of times, but which you apparently refused to read. 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] Accessing audio as root
On Thu, 2009-12-24 at 17:29 +0100, Lennart Poettering wrote: > On Wed, 23.12.09 15:26, Halim Sahin (halim.sa...@freenet.de) wrote: > > > > > Hi Col, > > 1. I gave you some examples what doesn't work as expected. > > How should I run my text-to-speech server before login to have > > audiooutput for reading the login screen? > > On Fedora at least the screenreader runs as normal process in the gdm > pseudo-session which also happens to run a PA instance. So everything > should be fine here, and I am quite sure this is not only done on > Fedora this way but all other distributions that use a current version > of gdm. Of course, if you use KDE things might be different... > > > 2. Running daemons worked well under alsa (see my previous post). > > I am using every day this setup. > > Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and > as such everything you could do with ALSA before stays available with > PA too. > > However input output deamons should definitely be part of the user > session. That is true for PA itself AND any kind of speech daemon and > suchlike. > > Lennart > I believe in his particular use-case he's concerned about the screenreader prior to the DE starting up (boot messages and the like?). ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 5:34 PM, Lennart Poettering wrote: > On Thu, 24.12.09 15:02, Markus Rechberger (mrechber...@gmail.com) wrote: > >> > All I'm saying is do you expect us to trawl the internet and dig up >> > problems without any kind of technical detail or debug info attached to >> > them or do you think we should concentrate on answering and dealing with >> > problems in a prescribed and constructive way - e.g. via our BTS. >> > >> > Honestly, give us solid bug reports and we'll attempt to fix the >> > problems reported, but don't come here spreading FUD and talking >> > bullshit throwing accusations without backing them up with anything >> > other than heresay. What I want for Christmas is BUG REPORTS with proper >> > debug information and trigger cases. >> >> I think it's pretty clear what the problem is. >> PA does not support multiple users on one system.. > > I'd prefer if you'd stop repeating this nonsense, which is simply not > true as I already pointed out a couple of times, but which you > apparently refused to read. > The only ones who are spreading around nonsense are you and Colin, do your homework get a Mac log in remotely as root or another user and try to use audio. You might be enlightened that it will work. Userbased or not it works on OSX. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 6:02 PM, Markus Rechberger wrote: > On Thu, Dec 24, 2009 at 5:34 PM, Lennart Poettering > wrote: >> On Thu, 24.12.09 15:02, Markus Rechberger (mrechber...@gmail.com) wrote: >> >>> > All I'm saying is do you expect us to trawl the internet and dig up >>> > problems without any kind of technical detail or debug info attached to >>> > them or do you think we should concentrate on answering and dealing with >>> > problems in a prescribed and constructive way - e.g. via our BTS. >>> > >>> > Honestly, give us solid bug reports and we'll attempt to fix the >>> > problems reported, but don't come here spreading FUD and talking >>> > bullshit throwing accusations without backing them up with anything >>> > other than heresay. What I want for Christmas is BUG REPORTS with proper >>> > debug information and trigger cases. >>> >>> I think it's pretty clear what the problem is. >>> PA does not support multiple users on one system.. >> >> I'd prefer if you'd stop repeating this nonsense, which is simply not >> true as I already pointed out a couple of times, but which you >> apparently refused to read. >> > > The only ones who are spreading around nonsense are you and Colin, > do your homework get a Mac log in remotely as root or another user > and try to use audio. You might be enlightened that it will work. > Userbased or not it works on OSX. > Anyway, please think about this entire issue after Christmas. Merry Chistmas to everyone! :-) Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoo...@gmail.com) wrote: > > Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and > > as such everything you could do with ALSA before stays available with > > PA too. > > > > However input output deamons should definitely be part of the user > > session. That is true for PA itself AND any kind of speech daemon and > > suchlike. > > > > Lennart > > > I believe in his particular use-case he's concerned about the > screenreader prior to the DE starting up (boot messages and the like?). We actually cover that inside of gdm, where you can get access to the boot messages. 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] Accessing audio as root
Hi, On Do, Dez 24, 2009 at 06:27:25 +0100, Lennart Poettering wrote: > On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoo...@gmail.com) wrote: > > > > Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and > > > as such everything you could do with ALSA before stays available with > > > PA too. > > > > > > However input output deamons should definitely be part of the user > > > session. That is true for PA itself AND any kind of speech daemon and > > > suchlike. > > > > > > Lennart > > > > > I believe in his particular use-case he's concerned about the > > screenreader prior to the DE starting up (boot messages and the like?). > > We actually cover that inside of gdm, where you can get access to the > boot messages. Ok what about consolescreenreaders like sbl brltty or speakup? They need a working audiosystem to provide usefull stuff before login or to read the login pprompt. With pulseaudio I need to login without feedback, start the speech server and then restart the screenreader. sorry folks I seems that you can't sink of usecases other than yours. Facts are: You have developed a new audio system which brings more flexibility and features to us. Unfortunately you expect that all projects should rewrite their audio stuff to work with your system. By design mac and windows are not comparable with linux because they are not a multi user OS. For german users: http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html changing the unix behaviour is the main problem here. Maybe you don't need this but others do. It should be possible to use the audiosystem the (old way). Just my 2 cents. Halim ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sat, 2009-12-26 at 08:31 +0100, Halim Sahin wrote: > Hi, > On Do, Dez 24, 2009 at 06:27:25 +0100, Lennart Poettering wrote: > > On Fri, 25.12.09 00:47, Ng Oon-Ee (ngoo...@gmail.com) wrote: > > > > > > Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and > > > > as such everything you could do with ALSA before stays available with > > > > PA too. > > > > > > > > However input output deamons should definitely be part of the user > > > > session. That is true for PA itself AND any kind of speech daemon and > > > > suchlike. > > > > > > > > Lennart > > > > > > > I believe in his particular use-case he's concerned about the > > > screenreader prior to the DE starting up (boot messages and the like?). > > > > We actually cover that inside of gdm, where you can get access to the > > boot messages. > > Ok what about consolescreenreaders like sbl brltty or speakup? > They need a working audiosystem to provide > usefull stuff before login or to read the login pprompt. > With pulseaudio I need to login without feedback, start the speech server and > then restart the screenreader. > > sorry folks I seems that you can't sink of usecases other than yours. > Facts are: > You have developed a new audio system which brings more flexibility and > features to us. > Unfortunately you expect that all projects should rewrite their audio > stuff to work with your system. > By design mac and windows are not comparable with linux > because they are not a multi user OS. > > For german users: > http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html > > changing the unix behaviour is the main problem here. > Maybe you don't need this but others do. > > It should be possible to use the audiosystem the (old way). > > Just my 2 cents. > Halim > I've been following these discussions with some (layman-level, I don't dev for pulse) interest, and I'm wondering whether a simple solution would be to use alsa-output prior to login and pulseaudio after login. A bit of configuration required instead of re-writing apps. Something would have to be done to get the screen reader to not hog the hw when the user is logged in, that shouldn't be too difficult though. I must admit its good to hear of an actual use-case where such behaviour is useful, instead of some of the random complaining that comes here seasonally. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sat, 26.12.09 18:03, Ng Oon-Ee (ngoo...@gmail.com) wrote: > I've been following these discussions with some (layman-level, I don't > dev for pulse) interest, and I'm wondering whether a simple solution > would be to use alsa-output prior to login and pulseaudio after login. A > bit of configuration required instead of re-writing apps. Something > would have to be done to get the screen reader to not hog the hw when > the user is logged in, that shouldn't be too difficult though. Yes, this is actually what I suggested a couple of times: it is possible to bypass PA, which is useful if you want to do audio outside of any session. 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] Accessing audio as root
On Sat, 26.12.09 08:31, Halim Sahin (halim.sa...@freenet.de) wrote: > > > > Lennart > > > > > > > I believe in his particular use-case he's concerned about the > > > screenreader prior to the DE starting up (boot messages and the like?). > > > > We actually cover that inside of gdm, where you can get access to the > > boot messages. > > Ok what about consolescreenreaders like sbl brltty or speakup? > They need a working audiosystem to provide > usefull stuff before login or to read the login pprompt. The gdm login screen should be prefectly accessible. > With pulseaudio I need to login without feedback, start the speech server and > then restart the screenreader. Use gdm! > By design mac and windows are not comparable with linux > because they are not a multi user OS. That is simply not true. > For german users: > http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html > > changing the unix behaviour is the main problem here. > Maybe you don't need this but others do. Unix is pretty much a broken system. It might be a useful base and more useful as a base than other systems, but uh, of course we need to deviate from a system that was designed 40 years ago. People who think that Unix is a flawless system and every depature from it would be bad are just incredibly naive. > It should be possible to use the audiosystem the (old way). You are always welcome to use a distribution from 3 years ago if you feel that progress is not for you... 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] Accessing audio as root
On Thu, Dec 17, 2009 at 4:52 AM, Lennart Poettering wrote: > I don't see why anyone would want to have audio when changing to root > for admin purposes. Playing music certainly does not fall under "admin > purposes". Ever consider what happens when a blind user switches to root, and his sound card stop speaking? This is no hypothetical situation, like someone trying to spy on me through Alsa by taking over my mike. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 6:57 AM, Lennart Poettering wrote: >> And this is the problem because it works with alsa, simply add every >> user you want to give audio access to the audio group and it worked. >> Even with OSS this worked. But PA breaks this behaviour. > > First of all, we broke exactly nothing. You can always bypass PA and do > stuff like this. > > Secondly, allowing access to the audio device to all users is a > security hole as I tried to explain quite a few times. Allowing that > means a user can evesdrop into your voip calls, he can even completely > monitor whatever you say when you sit in front of your computer. How can I "bypass PA" on a Ubuntu Karmic or Lucid? If I disable user-land pulseaudio, several applications break, including the volume control. PulseAudio has been Vulcan mind-melded into the system. If you know of a realistic way to bypass PulseAudio, by all means, please state it! If sound were just for music, this wouldn't be a big deal. Speakup needs to route speech to the sound card, regardless of who is logged in, and in parallel with whatever music or speech they are playing. PulseAudio has broken Linux accesibility for the blind quite seriously. I'm a C coder, willing to help. Got any ideas for a solution? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Wed, Dec 23, 2009 at 9:13 AM, Colin Guthrie wrote: 'Twas brillig, and Halim Sahin at 23/12/09 13:24 did gyre and gimble: >> The Problem can be summarized in one sentence: >> Pulseaudio currently breaks multiuser systems and is only useful for >> one-user-desktop. > > Actually no, the exact opposite. PA works very well for multi user > desktops. Hi, Col. Let me say I'm beginning to be a fan of your posts, as I read more of them. This is probably an Ubuntu issue, but in Karmic and Lucid, Switch User does not change the permissions for the sound card, and the new user will be mute. It's a fairly minor bug... the work-around is logout and log back in. IMO, Halim's more important comment was that PulseAudio breaks accessibility. Speakup is either the #1 or #2 most popular Linux accessibility program for the blind and visually impaired. It starts at boot, as it should, so a blind person can hear what's going on. Gdm kills PulseAudio when a user logs in. Speakup runs forever, and it' PulseAudio process hangs around forever, locking up the sound card, so the user can't get any sound in Gnome. I'm not a bad C coder. I can patch this and make it work. But I don't want to go writing a random work-around blindly! I need advice as what the right solution is. Here's one thought, but I haven't examined the code effected. What if we allow certain users parallel access to particular sound card? Speakup launches speechd-up which launches speech-dispatcher during boot, as user 'speech-dispatcher'. If speech-dispatcher ran as gdm instead, and we allowed gdm to always access the sound card? That way, gdm would reuse speech-dispatcher's copy of pulseaudio rather than making a new one, and we'd no longer have to worry about killing gdm's copy of pulseaudio when a user logs in, or restarting it when he logs out. Is that the best way to patch this system? Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie wrote: > 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: >> I think it's pretty clear what the problem is. >> PA does not support multiple users on one system.. >> I told you if you intend to replace the existing audio system and >> build up compatibility layers >> add try to do it right. > > But for you "right" === "the exact same way it used to work". Hi, Colin. I think it is important to understand where people like Markus come from. I suspect he's completely blind. "Right" for him means his system talks to him at boot, in both speakup and Orca and probably a few other apps. "Wrong" is when the sound system stops speakup or Orca from talking. It's the ultimate show-stopper bug for the blind. Losing sound for a blind person is about as scary as a hard-disk crash - maybe worse! A blind person often has to track down a sighted person with the skills to repair his software in person. This can be a lot harder than installing a new hard drive and OS. I want to help constructively. I want to track down the problem and suggest a patch. Any guidance as to the approach to take would be very welcome - I really don't know the PulseAudio system well enough to determine the best approach. Eventually, I'll just pick one and do it, but it's worth begging for advice if I can get it! Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 11:29 AM, Lennart Poettering wrote: > On Wed, 23.12.09 15:26, Halim Sahin (halim.sa...@freenet.de) wrote: > >> >> Hi Col, >> 1. I gave you some examples what doesn't work as expected. >> How should I run my text-to-speech server before login to have >> audiooutput for reading the login screen? > > On Fedora at least the screenreader runs as normal process in the gdm > pseudo-session which also happens to run a PA instance. So everything > should be fine here, and I am quite sure this is not only done on > Fedora this way but all other distributions that use a current version > of gdm. Lennart, let me explain how blind people use Linux. There are TWO applications in common use - Orca and Speakup. Actually, there's a third - emacspeak, but let's not go there, yet. Orca is the screen reader that you are talking about. It runs as user, and can be made to work well with PulseAudio. I've personally helped in that effort (I wrote a new pulseaudio driver for it). The other critical application is Speakup. It runs as a kernel module and speaks every bit of console output during the boot process. Many blind people rely heavily on Speakup, and only use Orca for websites that require Firefox to read. >> 2. Running daemons worked well under alsa (see my previous post). >> I am using every day this setup. > > Running PA doesn't mean ALSA is out of the game. PA builds on ALSA and > as such everything you could do with ALSA before stays available with > PA too. > > However input output deamons should definitely be part of the user > session. That is true for PA itself AND any kind of speech daemon and > suchlike. Output deamons do belong in the user session, but not all speech deamons do. Speakup, in particular, is a kernel module. It's job is speaking all console output to the user. The blind don't give a hoot how we get speach from /dev/speakup_soft to the sound card. It just has to happen. Today, on every pulseaudio enabled system I know of, this does not work properly. I tried setting speakup to use alsa, and it works, right up until pulseaudio for gdm starts. After that, speakup is mute. Is there any way for pulseaudio to share the sound card with speakup/alsa? Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Thu, Dec 24, 2009 at 12:27 PM, Lennart Poettering wrote: > We actually cover that inside of gdm, where you can get access to the > boot messages. > > Lennart Speakup doesn't stop reading when the user logs into Gnome. When we type Ctrl+Alt+F1, we get a console screen which is read by speakup. It reads the login prompt, and then all the console text after login, whether as a normal user, or as root. It runs in parallel with Gnome, and never exits until shutdown. Most blind Linux users I know love this behaviour, and will not consider Linux distros that don't support it. This is why web sites like this recoment removing PulseAudio from Ubuntu: http://live.gnome.org/Orca/UbuntuKarmic This is why Ubuntu disables PulseAudio if the user selects an "accessible install". I would like to help Ubuntu keep PulseAudio even with an accessible install. Any "right" solution should require little and probably zero changes to programs like speakup. We should be able to tell the sound system that speakup is allowed to share the sound card with PA. Speakup already has both pulseaudio and alsa drivers, and if we can get either working with PA in parallel, we're in good shape. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Fri, 2010-01-01 at 23:29 -0500, Bill Cox wrote: > On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie wrote: > > 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: > >> I think it's pretty clear what the problem is. > >> PA does not support multiple users on one system.. > >> I told you if you intend to replace the existing audio system and > >> build up compatibility layers > >> add try to do it right. > > > > But for you "right" === "the exact same way it used to work". > > Hi, Colin. I think it is important to understand where people like > Markus come from. I suspect he's completely blind. Sorry, I'm pretty sure from previous mails from Markus that his main issue is a certain hardware his company sells which requires root to be able to access pulseaudio, some TV-sort thingy. He's mentioned this repeatedly in the months I've been on this list. Sorry I can't help more with your issue, I've been reading the conversations about it and think you have a point, but it'll be quite a bit of work to get things working. It may perhaps be better to use alsa with dmix as markus has suggested. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
pe, 2010-01-01 kello 23:13 -0500, Bill Cox kirjoitti: > IMO, Halim's more important comment was that PulseAudio breaks > accessibility. Speakup is either the #1 or #2 most popular Linux > accessibility program for the blind and visually impaired. It starts > at boot, as it should, so a blind person can hear what's going on. > > Gdm kills PulseAudio when a user logs in. Speakup runs forever, and > it' PulseAudio process hangs around forever, locking up the sound > card, so the user can't get any sound in Gnome. If speakup's model is that the daemon runs forever, without changing the user when sessions are switched, it's in conflict with the normal pulseaudio model, ie. the currently active user owns the sound hardware. If the two programs are to be used simultaneously, one of these two models has to change. Pulseaudio's model can be changed by running it in system wide mode. That's a viable solution, but not ideal for the known reasons. Another approach, which you seem to have started thinking about, is modifying pulseaudio's normal operating model so that it's compatible with speakup. This approach should be used if speakup's current model is correct. Otherwise speakup should be modified. My personal opinion is that speakup's model is not correct, but since I'm not going to do any coding related to this anyway, my opinion is irrelevant. But here's how I see speakup should work, judge for yourself if it makes any sense: At boot --- At boot time there isn't really anybody having a private session; the boot messages are public. Speakup should run as user "anybody" (that's just a placeholder), and this "anybody" user has his own pulseaudio daemon running. Then either gdm or a console login manager starts. In my opinion, they should also run as "anybody", but there are probably reasons why gdm runs as user "gdm". That's why I use "anybody" just as a placeholder - speakup may also have to use a custom user. At login After logging in, the current session has become private to the logged in user. The pulseaudio daemon that the login manager used releases the sound card, and a new pulseaudio daemon is launched for the user. Now speakup has to start to use the user's pulseaudio. This happens by starting a new speakup daemon instance as part of the user's session setup. Regarding this handover, it may need more or less logic in speakup - I don't know how speakup works. If only one daemon can use /dev/speakup_soft at a time, the previous instance needs to use consolekit to know when to release the access to /dev/speakup_soft and acquire it again when its session becomes active. The pulseaudio daemon of the "anybody" user stays running, streams to the sound card are just suspended. Speakup should probably detect this and close the stream when the session is deactivated, because when the session is activated again, I suspect you don't want to continue speaking from where you left off. Switching virtual terminals --- Switching virtual terminals works similarly to the login case. The access to the sound card moves from one user to another (might be "anybody" - in theory it doesn't make any difference whether the terminals have someone actually logged in or if the terminal user is the "anybody" dummy user). So that's how I see it should work. I'm not very confident when speaking about consolekit and boot/login processes, so I have to hope that the system I described isn't too different from how things work in reality. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Bill Cox wrote: > On Thu, Dec 24, 2009 at 12:27 PM, Lennart Poettering > wrote: >> We actually cover that inside of gdm, where you can get access to the >> boot messages. >> >> Lennart > > Speakup doesn't stop reading when the user logs into Gnome. When we > type Ctrl+Alt+F1, we get a console screen which is read by speakup. > It reads the login prompt, and then all the console text after login, > whether as a normal user, or as root. It runs in parallel with Gnome, > and never exits until shutdown. Most blind Linux users I know love > this behaviour, and will not consider Linux distros that don't support > it. I was just thinking, and this idea is perhaps not 100% thought through, but it could be worth considering. We have this hand-over mechanism: http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt It looks nice, except for that it lives on the session D-bus. Now assume we move (or copy) it to the system D-bus instead. Then we implement the handover request in speakup, timidity, and other programs not running inside the session context. This seems like a working middle-way between using the user's PulseAudio (which seems difficult, especially when it changes) and the path of uninstalling PulseAudio completely. I'm not a qualified plumber, so I could possibly be missing something obvious here. What do you think? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Tanu Kaskinen at 02/01/10 05:59 did gyre and gimble: > So that's how I see it should work. I'm not very confident when speaking > about consolekit and boot/login processes, so I have to hope that the > system I described isn't too different from how things work in reality. I think I agree more or less, but with perhaps a few caveats/clarifications. 1. I think the "anybody" user is a valid concept. I'd personally call it the "idle" or "inactive" user as homage to the active denomination in consolekit already. To run some practical tests, if you run: [co...@jimmy ~]$ ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = TRUE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' you can see that I am the "active" user currently. If however I run the following and then switch to the login window on tty1: [co...@jimmy ~]$ sleep 3; ck-list-sessions Session1: unix-user = '603' realname = 'Colin Guthrie' seat = 'Seat1' session-type = '' active = FALSE x11-display = ':0' x11-display-device = '/dev/tty7' display-device = '' remote-host-name = '' is-local = TRUE on-since = '2009-12-30T09:40:14.334448Z' login-session-id = '4294967295' Here we see that no user is currently "active". In this mode no user is active on my system - i.e. it's "idle". Now lets think about permissions. Some folks have recently mentioned the "audio" group. This is a relic and should not be used or considered for controlling access to audio hardware. The real way forward is the interaction between udev and console kit applying ACLs for the appropriate users. Now in this case we really need to define a user on the system who is "idle". Both udev and console-kit probably need to be aware of this concept and write the appropriate ACLs to the sound hardware for the "idle" user, removing them when a real user logs in (and in this case "gdm" should be considered a "real" user. In this case the boot scenario (permissions wise) would be as follows: 1. Turn on (this will rarely change and I predict will remain the first step for many years :p) 2. udev kicks in. 3. system dbus starts 4. consolekit starts and due to no active users instructs udev to write the idle user to the audio device node ACLs (I'm not 100% sure whether udev drives console-kit or the other way round, so someone more familiar than me with this can hopefully clarify) 5. Some special handling in the boot process will launch speakupd as the idle user (I think this is appropriate - there should not (IMO) be a central daemon for sepakupd - it should be launched when needed). I'm not specifically sure if it is the "boot up" process per-se or the "system becomes idle" case that really should be responsible for starting speakupd... My gut feeling is that console-kit should be aware of "idle" status and have a set of hooks that can be run when this happens. These hooks could then be used to start speakupd as the idle user). At this stage the idle user can now start talking about what is going on with the boot. 6. X is launched and GDM (or equiv) is started, console-kit will now realise there is an active session started for the gdm user and remove the ACLs on the sound device. The idle user's speakupd can die as can it's PA instance. GDM user will start it's own speakupd and PA process. 7. If at this stage the user logs in graphically then the same thing as idle->gdm happens. The gdm user's PA and speakupd process dies and the real user's one will kick in. 7b. Now if the user switches to tty1 (whether at gdm login screen or after logging in - the concept is the same), console-kit will notice the system has become idle and apply the appropriate ACLs, due the "idle hooks" mentioned in 5 above, speakupd/PA will be launched and the login prompt can be described audibly. Once logging in the user becomes active again, so the idle user is killed off as before and can hand over to the real user. Thinking about it, I think that consolekit itself is really what should be responsible for starting speakupd (which will in turn start pulseaudio if appropriate). I think that some kind of "system becomes idle" and "user becomes active" hooks would provide the necessary framework into which speakupd could integrate. The concepts of "starting a service" are starting to erode these days with more and more things being triggered from udev, so the general migration to this approach (i.e. making speakupd "serviceless") seems to be followed with the above suggestion too. Also on a system shared by both blind and sighted users there does not need to be any special support for detecting the current user
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Bill Cox at 02/01/10 04:29 did gyre and gimble: > On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie wrote: >> 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: >>> I think it's pretty clear what the problem is. >>> PA does not support multiple users on one system.. >>> I told you if you intend to replace the existing audio system and >>> build up compatibility layers >>> add try to do it right. >> >> But for you "right" === "the exact same way it used to work". > > Hi, Colin. I think it is important to understand where people like > Markus come from. I suspect he's completely blind. "Right" for him > means his system talks to him at boot, in both speakup and Orca and > probably a few other apps. He's not blind as far as I know, but one think he definitely doesn't like is change or changes to things that used to work in his sphere of interest. In this case I he was talking about doing things "right" but what he actually wanted was to do things the way it has been done in the past to the exclusion of all other things. I was merely making the observation that just because something worked in one way at one point in time that it does not make it inherently "right". I did not deal with the opposite case (e.g. just because something is different it's not automatically wrong - of course it *could* be wrong, but it's not implied). > "Wrong" is when the sound system stops speakup or Orca from talking. Yes I agree in principle - the system should have the necessary infrastructure in place to make this all work, but that's not to say that keeping things modeled on the old behaviour is "right". > It's the ultimate show-stopper bug for > the blind. Losing sound for a blind person is about as scary as a > hard-disk crash - maybe worse! A blind person often has to track down > a sighted person with the skills to repair his software in person. > This can be a lot harder than installing a new hard drive and OS. Yes, I appreciate this and certainly do not disagree. > I want to help constructively. I want to track down the problem and > suggest a patch. Any guidance as to the approach to take would be > very welcome - I really don't know the PulseAudio system well enough > to determine the best approach. Eventually, I'll just pick one and do > it, but it's worth begging for advice if I can get it! Indeed and having these discussions and getting input from people here is certainly the right start to this approach. I can tell from your messages and general approach that you are very open to suggestions. It's sad that the current state of affairs is one in which certain subsystems are not working too well, but it's one of the natural parts of FOSS development. Even if before PA had landed in distros we have reached out to every corner of development and said "there is a change coming, please be ready", we'd still be in the same position as we are now. Developers always need a stick rather than a carrot when dealing with separate parts of a shared infrastructure. It's the reason KDE 4 was released when it was - there was massive outcry by users saying "it isn't ready" etc regardless of numerous warnings from developers that 4.0 was more of a developer release designed to encourage various app developers to step up their porting efforts (i.e. the stick rather than the carrot). Other software projects have had the same issue too, and while it's not ideal, the disparate nature of FOSS work means that the coordination is generally not possible to get things all nicely working before adoption - the audience is simply not big enough. So sometimes things suck, but then they get better. Hopefully you're one of the people who will help this particular sucky thing get better :) Take care 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] Accessing audio as root
Hi, David. On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson wrote: > I was just thinking, and this idea is perhaps not 100% thought through, > but it could be worth considering. > > We have this hand-over mechanism: > > http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt You obviously know more about the plumbing than I do! I don't know anything about d-bus, so my opinion counts little, but it looks like a good direction to me. I would want to bury all the complexity of dealing with d-bus under the pulse-simple API, so that only a one-line change has to be made to clients like speakup/espeakup and speakup/speechd-up. I'm not quite sure how this works. When a speakup client wants access to the sound card, it could request access at high priority, and then plays it's sound. How would it hand back the sound card to the other user and uncork it? If this were automatic once the queue was empty for say one second, that would be great. Is this the sort of thing we can do with PA/CK? Thanks, Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Hi, Colin. I agree with 100% or your message. The blind are about the worst adopters of new technology you'll run across. In fact, the only reason you're hearing from me is that Ubuntu has made it more or less a bug to remove PA. Otherwise, I'd join the rest of the blind/VI community of embracing what worked in the past for as long as possible. If I were fully blind, rather than just a bit visually impaired, you wouldn't even hear from me, other than perhaps some of my usual grumpy ranting. As it is, I can still work quite well on fixing systems without speech, and with PA becoming standard, I'm highly motivated to get it working well for the blind. Especially before my vision fades much further. So, for me the "right" behaviour is not simply the old behaviour. In this case, I think that the "right" behaviour is some solution that maintains the security of PA, while not burdening the various "global" sound sources with details of working with d-bus, or CK. I'd like to make it a simple one-line option set in pulse-simple to enable a sound driver as "global", control security with group and user access, and bury the complexity under the hood, so the client wont have to deal with it. If you think it's hard to get upstream devs to adopt PA support, wait until you try to get blind upstream devs to change their code! Actually, they're typically very apriciative of any help they can get, but the #1 rule is you can't break what works. I put out a simple request last week, "Can I join the speakup dev team for a while" the silence was deafening. I think whatever solution we come up with needs to simplify their life as much as possible. By the way, I am a fan of pulse-simple. It's as easy an interface as I've seen, while still exposing important buffering parameters. It's working well with Orca. I looked at the implementation code in pulse and pulse-core. It's good code. It's clear that the author had some skill. Bill On Sat, Jan 2, 2010 at 9:25 AM, Colin Guthrie wrote: > 'Twas brillig, and Bill Cox at 02/01/10 04:29 did gyre and gimble: >> On Thu, Dec 24, 2009 at 11:14 AM, Colin Guthrie wrote: >>> 'Twas brillig, and Markus Rechberger at 24/12/09 14:02 did gyre and gimble: I think it's pretty clear what the problem is. PA does not support multiple users on one system.. I told you if you intend to replace the existing audio system and build up compatibility layers add try to do it right. >>> >>> But for you "right" === "the exact same way it used to work". >> >> Hi, Colin. I think it is important to understand where people like >> Markus come from. I suspect he's completely blind. "Right" for him >> means his system talks to him at boot, in both speakup and Orca and >> probably a few other apps. > > He's not blind as far as I know, but one think he definitely doesn't > like is change or changes to things that used to work in his sphere of > interest. In this case I he was talking about doing things "right" but > what he actually wanted was to do things the way it has been done in the > past to the exclusion of all other things. I was merely making the > observation that just because something worked in one way at one point > in time that it does not make it inherently "right". I did not deal with > the opposite case (e.g. just because something is different it's not > automatically wrong - of course it *could* be wrong, but it's not implied). > >> "Wrong" is when the sound system stops speakup or Orca from talking. > > Yes I agree in principle - the system should have the necessary > infrastructure in place to make this all work, but that's not to say > that keeping things modeled on the old behaviour is "right". > > >> It's the ultimate show-stopper bug for >> the blind. Losing sound for a blind person is about as scary as a >> hard-disk crash - maybe worse! A blind person often has to track down >> a sighted person with the skills to repair his software in person. >> This can be a lot harder than installing a new hard drive and OS. > > Yes, I appreciate this and certainly do not disagree. > >> I want to help constructively. I want to track down the problem and >> suggest a patch. Any guidance as to the approach to take would be >> very welcome - I really don't know the PulseAudio system well enough >> to determine the best approach. Eventually, I'll just pick one and do >> it, but it's worth begging for advice if I can get it! > > Indeed and having these discussions and getting input from people here > is certainly the right start to this approach. I can tell from your > messages and general approach that you are very open to suggestions. > > It's sad that the current state of affairs is one in which certain > subsystems are not working too well, but it's one of the natural parts > of FOSS development. Even if before PA had landed in distros we have > reached out to every corner of development and said "there is a change > coming, please be ready", we
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble: > Hi, David. > > On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson > wrote: >> I was just thinking, and this idea is perhaps not 100% thought through, >> but it could be worth considering. >> >> We have this hand-over mechanism: >> >> http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt > > You obviously know more about the plumbing than I do! I don't know > anything about d-bus, so my opinion counts little, but it looks like a > good direction to me. I would want to bury all the complexity of > dealing with d-bus under the pulse-simple API, so that only a one-line > change has to be made to clients like speakup/espeakup and > speakup/speechd-up. > > I'm not quite sure how this works. When a speakup client wants access > to the sound card, it could request access at high priority, and then > plays it's sound. How would it hand back the sound card to the other > user and uncork it? If this were automatic once the queue was empty > for say one second, that would be great. Is this the sort of thing we > can do with PA/CK? While this would theoretically work, I think it's probably not needed. The reservation system is really meant for interacting with jack and while it's not exclusive, I think it's not really an appropriate technique to solve this problem. I think the general concept of the speech dispatchers running as a system service is the bit that needs re-thought and that adding hooks to consolekit (if they don't exist) and the concept of an "idle user" are probably more practical long term solutions. Of course I could be wrong on that front :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] Accessing audio as root
Hi, Col. I'm willing to try the aproach you suggest, but I'd like to debate the implementation some more. If I understand correctly, I can use CK to determine whenever the sound card permissions are moved to a new user (which is basically whenever a user takes over the "seat", except as root), and can then launch the various accessibility apps the user needs as that user. Is this basically correct? Since there are several apps that are candidates, I'm tempted to allow them to be listed in some /etc config file, rather than duplicating the code for each. That would provide users a mechanism for having apps follow the sound card. Should I make this a PA capability with a PA module? If I made this a PA module, and if I'm basically trying to kill client apps when PA loses a sound card, and launch client apps when it gains a sound card, then might it make sense to add a hook within PA to do this, and not deal with CK? Probably because I've read some PA code, and not CK, I'm thinking it would be easier and more robust. Why do I need to have an idle hook? It sounded good when I read it the first time, but now I'm confused. Thanks, Bill On Sat, Jan 2, 2010 at 11:52 AM, Colin Guthrie wrote: > 'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble: >> Hi, David. >> >> On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson >> wrote: >>> I was just thinking, and this idea is perhaps not 100% thought through, >>> but it could be worth considering. >>> >>> We have this hand-over mechanism: >>> >>> http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt >> >> You obviously know more about the plumbing than I do! I don't know >> anything about d-bus, so my opinion counts little, but it looks like a >> good direction to me. I would want to bury all the complexity of >> dealing with d-bus under the pulse-simple API, so that only a one-line >> change has to be made to clients like speakup/espeakup and >> speakup/speechd-up. >> >> I'm not quite sure how this works. When a speakup client wants access >> to the sound card, it could request access at high priority, and then >> plays it's sound. How would it hand back the sound card to the other >> user and uncork it? If this were automatic once the queue was empty >> for say one second, that would be great. Is this the sort of thing we >> can do with PA/CK? > > While this would theoretically work, I think it's probably not needed. > The reservation system is really meant for interacting with jack and > while it's not exclusive, I think it's not really an appropriate > technique to solve this problem. > > I think the general concept of the speech dispatchers running as a > system service is the bit that needs re-thought and that adding hooks to > consolekit (if they don't exist) and the concept of an "idle user" are > probably more practical long term solutions. > > Of course I could be wrong on that front :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] Accessing audio as root
'Twas brillig, and Bill Cox at 02/01/10 21:03 did gyre and gimble: > Hi, Col. I'm willing to try the aproach you suggest, but I'd like to > debate the implementation some more. If I understand correctly, I can > use CK to determine whenever the sound card permissions are moved to a > new user (which is basically whenever a user takes over the "seat", > except as root), and can then launch the various accessibility apps > the user needs as that user. Is this basically correct? Since there > are several apps that are candidates, I'm tempted to allow them to be > listed in some /etc config file, rather than duplicating the code for > each. That would provide users a mechanism for having apps follow the > sound card. Should I make this a PA capability with a PA module? Right in principle but not quite what I was suggesting in practice. Essentially I am suggesting that console kit is altered to have a set of hooks that it itself runs. Your system will be running the console-kit-daemon and it already has folders like: /usr/lib/ConsoleKit/run-session.d Which is run when a new user logs in. What I am suggesting is to add the concept of the "idle" session and a system "idle" user. > If I made this a PA module, and if I'm basically trying to kill client > apps when PA loses a sound card, and launch client apps when it gains > a sound card, then might it make sense to add a hook within PA to do > this, and not deal with CK? No, this is totally impossible - remember that there are multiple PA processes, one for each user. The above suggestion would only work if there was a single PA daemon for all users. This is why I think console-kit is the correct place to do this - there is a single system-wide daemon running here and it already has a hooks system. PA clients should never be killed - they will just be corked if the user becomes inactive and uncorked when they become active again. > Probably because I've read some PA code, > and not CK, I'm thinking it would be easier and more robust. Sadly this is the wrong concept and not what I've actually been suggesting. I'd recommend you read up on console-kit a bit and perhaps speak to some of their devs about it and see whether what I'm suggesting is sensible or not. > Why do I need to have an idle hook? It sounded good when I read it > the first time, but now I'm confused. This is the key thing about what I'm suggesting. When you switch to the login prompt on tty1, there is no active user but yet you still want the prompt to be read out and have sound. For this I suggest adding the concept of an idle system. This should be the same as the gdm login screen really but it runs a real (albeit psuedo) session under the gdm user. The same is not true for tty logins which is why I think an idle user should take this job. It may or may not make sense for gdm to be run as the idle user too rather than it's own dedicated user. Anyway when the system becomes idle (e.g. tty1 prompt) this basically means no user is active and implies either a status screen or a login prompt. When the user becomes idle the hooks installed to consolekit by the speechd-up package will cause the speechd-up daemon to be run. This daemon will then be able to speak the login prompt. When the user logs in, console-kit will be informed about this and the idle session will be killed (or suspended) and then the user's own session will be start. The hooks for "user logs in" in consolekit can then start a speechd-up process for that user if it's not already running (if it's running already from a graphical session and the user switches to tty1 and logs in the speechd-up already running from the graphicial login will just be reused). This is very much the same principle as pulseaudio itself (e.g. one PA process runs for a given user even if they are logged in mulitple times). The difference from PA is that speechd-up cannot use autospawning to launch, which is why I'm suggesting leveraging console-kit to actually *start* the speechd-up process. I'm probably not explaining it very well so I'll try and reiterate when I'm not quite as tired with a few examples. Col (Of course all my suggestions today could be way off base so it would be much better if someone more familiar in the inner workings could validate (or invalidate!) what I've said before you go off and do anything implementation wise!) -- 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] Accessing audio as root
This scheme sounds reasonable, though whenever someone says "impossible", I'm naturally inclined to give it a solid try. Why would it be impossible to add PA hooks I could run when PA gains, uncorks, corks, or delets a connection to a card? I thought I already saw a system of hooks being called. I'm worried that if I follow the user instead using CK, and my logic for card access transfer does not match PA's, then I might transfer speach while PA does not transfer audio card access. We have to kill the user's speech-dispatcher and speechd-up deamons when access to a card is transfered to a new PA instance. There can only be one speechd-up and one speech-dispatcher process at a time. For one think, speechd-up locks the /dev/softsynth device, and the second speechd-up wont even run. speech-dispatcher opens a port, which speechd-up uses for communication, and multiple speech-dispatchers conflict on the port. But, it should not be a problem restarting these deamons as needed. If the audio card leaves, there's no reason to have these processes hanging around. Bill On Sat, Jan 2, 2010 at 4:47 PM, Colin Guthrie wrote: > 'Twas brillig, and Bill Cox at 02/01/10 21:03 did gyre and gimble: >> Hi, Col. I'm willing to try the aproach you suggest, but I'd like to >> debate the implementation some more. If I understand correctly, I can >> use CK to determine whenever the sound card permissions are moved to a >> new user (which is basically whenever a user takes over the "seat", >> except as root), and can then launch the various accessibility apps >> the user needs as that user. Is this basically correct? Since there >> are several apps that are candidates, I'm tempted to allow them to be >> listed in some /etc config file, rather than duplicating the code for >> each. That would provide users a mechanism for having apps follow the >> sound card. Should I make this a PA capability with a PA module? > > Right in principle but not quite what I was suggesting in practice. > > Essentially I am suggesting that console kit is altered to have a set of > hooks that it itself runs. > > Your system will be running the console-kit-daemon and it already has > folders like: > > /usr/lib/ConsoleKit/run-session.d > > Which is run when a new user logs in. > > What I am suggesting is to add the concept of the "idle" session and a > system "idle" user. > > >> If I made this a PA module, and if I'm basically trying to kill client >> apps when PA loses a sound card, and launch client apps when it gains >> a sound card, then might it make sense to add a hook within PA to do >> this, and not deal with CK? > > No, this is totally impossible - remember that there are multiple PA > processes, one for each user. The above suggestion would only work if > there was a single PA daemon for all users. This is why I think > console-kit is the correct place to do this - there is a single > system-wide daemon running here and it already has a hooks system. > > PA clients should never be killed - they will just be corked if the user > becomes inactive and uncorked when they become active again. > > >> Probably because I've read some PA code, >> and not CK, I'm thinking it would be easier and more robust. > > Sadly this is the wrong concept and not what I've actually been > suggesting. I'd recommend you read up on console-kit a bit and perhaps > speak to some of their devs about it and see whether what I'm suggesting > is sensible or not. > >> Why do I need to have an idle hook? It sounded good when I read it >> the first time, but now I'm confused. > > This is the key thing about what I'm suggesting. When you switch to the > login prompt on tty1, there is no active user but yet you still want the > prompt to be read out and have sound. For this I suggest adding the > concept of an idle system. This should be the same as the gdm login > screen really but it runs a real (albeit psuedo) session under the gdm > user. The same is not true for tty logins which is why I think an idle > user should take this job. It may or may not make sense for gdm to be > run as the idle user too rather than it's own dedicated user. > > Anyway when the system becomes idle (e.g. tty1 prompt) this basically > means no user is active and implies either a status screen or a login > prompt. When the user becomes idle the hooks installed to consolekit by > the speechd-up package will cause the speechd-up daemon to be run. This > daemon will then be able to speak the login prompt. When the user logs > in, console-kit will be informed about this and the idle session will be > killed (or suspended) and then the user's own session will be start. The > hooks for "user logs in" in consolekit can then start a speechd-up > process for that user if it's not already running (if it's running > already from a graphical session and the user switches to tty1 and logs > in the speechd-up already running from the graphicial login will just be > reused). > > This is very much the sa
Re: [pulseaudio-discuss] Accessing audio as root
I spent a few hours trying to figure out how well this scheme could work for Ubuntu/Lucid. Things are in bad shape. Speakup basically is incompatible with PA on Lucid for now. The problems seem to come from multiple PA instances not sharing properly. If you switch-user to a new user on Karmic or Lucid, the new user has no access to the sound card. With the gdm PA instance running inorder to speak console login prompts, and the user PA running in Gnome, I can't get both to work at the same time. Since I'm not aware of any time that this has ever worked properly on Ubuntu with PA, I suspect it may be years before these issues are fixed. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
Sorry... my laptop has a tendency to accidentally click, and I sent that last e-mail unfinished. Anyway, I don't believe I've evern seen multiple copies of PA running in Ubuntu work properly together, and the open bug about this on bugs.launchpad.net has had no progress or interest. If I write the CK code to kill speech-dispatcher and relaunch it when we switch user, it wont work in Ubuntu. IMO, the prudent thing to do for the Lucid release is guide blind users to be sure they only have one PA instance at a time. In particular, I'm thinking of requiring that they log in through gdm before switching to a console (for the non-CLI version). We can add speechd-up as a startup application to be automatically launched after speech-dispatcher and Orca. When I do this in Karmic, the consoles have good speakup performance. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
(Answer to both Colin and Bill) Colin Guthrie wrote: > 'Twas brillig, and Bill Cox at 02/01/10 15:03 did gyre and gimble: >> Hi, David. >> >> On Sat, Jan 2, 2010 at 1:08 AM, David Henningsson >> wrote: >>> I was just thinking, and this idea is perhaps not 100% thought through, >>> but it could be worth considering. >>> >>> We have this hand-over mechanism: >>> >>> http://git.0pointer.de/?p=reserve.git;a=blob_plain;f=reserve.txt >> You obviously know more about the plumbing than I do! I don't know >> anything about d-bus, so my opinion counts little, but it looks like a >> good direction to me. I would want to bury all the complexity of >> dealing with d-bus under the pulse-simple API, so that only a one-line >> change has to be made to clients like speakup/espeakup and >> speakup/speechd-up. You're talking about the pulse-simple API here, I thought the speech daemon, timidity etc were using ALSA directly? Are you planning to change that? (And if you do, what consequences will that bring to speakup being able to talk when PulseAudio is down?) >> I'm not quite sure how this works. When a speakup client wants access >> to the sound card, it could request access at high priority, and then >> plays it's sound. How would it hand back the sound card to the other >> user and uncork it? Good question. I'm assuming it is handled in a good way already between PulseAudio and Jack and that way could work here as well. I think one can listen to org.freedesktop.DBus.NameOwnerChanged, or just poll once a second. However the reserve API does not currently handle (in the best way) if there is more than one client waiting for the soundcard. >> If this were automatic once the queue was empty >> for say one second, that would be great. Is this the sort of thing we >> can do with PA/CK? > While this would theoretically work, I think it's probably not needed. > The reservation system is really meant for interacting with jack and > while it's not exclusive, I think it's not really an appropriate > technique to solve this problem. > > I think the general concept of the speech dispatchers running as a > system service is the bit that needs re-thought and that adding hooks to > consolekit (if they don't exist) and the concept of an "idle user" are > probably more practical long term solutions. > > Of course I could be wrong on that front :p Taking it a step back, and looking at it from a higher, conceptual level, I think it depends on how you view upon the soundcard. If you view it as a part of the seat (as in ConsoleKit's definition), then the ConsoleKit approach makes most sense. If you view the soundcard as a system-wide resource, it makes more sense to make the reserve API system-wide as well. PulseAudio has taken the "seat" approach, whereas the speak server has taken the "system-wide resource" approach. And I personally think both views are equally valid - after all, we don't know anything about the actual physical location of the speakers/mic! So for PulseAudio to be a little friendly in a heterogeneous world, would it hurt to move/copy the reserve API to the system d-bus? Then it would be up to the speech daemon, timidity, and the others, to make their own choice whether they want to integrate with ConsoleKit and get the mixing features of PulseAudio, or - a little more quick and dirty, perhaps - just request the device on the d-bus. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, Jan 3, 2010 at 12:59 AM, Bill Cox wrote: > Anyway, I don't believe I've evern seen multiple copies of PA running > in Ubuntu work properly together, and the open bug about this on > bugs.launchpad.net has had no progress or interest. If I write the CK > code to kill speech-dispatcher and relaunch it when we switch user, it > wont work in Ubuntu. I can't reproduce this symptom [of not having CK work properly] in a Lucid live disc (daily), so I'm really quite interested in fixing where in PA/CK it's broken in Lucid. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Bill Cox at 02/01/10 22:37 did gyre and gimble: > This scheme sounds reasonable, though whenever someone says > "impossible", I'm naturally inclined to give it a solid try. Well of course it's not impossible, suitible changes all round could enable it. I should really have said not sensible. It's definitely not the approach I would take. > Why > would it be impossible to add PA hooks I could run when PA gains, > uncorks, corks, or delets a connection to a card? I thought I already > saw a system of hooks being called. There is a perfectly good system of hooks etc. inside PA but it all deals with scenarios *inside a given user session*. Once the user loses control of the sound hardware you should really think of that users PA process going to sleep and not doing anything useful until it gets its access back again. The whole problem you're trying to solve here is two fold: 1) when a given user is not actually logged in yet and the system is idle/at gdm login. and 2) When multiple users are logged in and we're switching between logins. In all cases I'm suggesting using a user account of some sort: e.g. the users bill and colin for the real logins and the users gdm and idle for the login screens. This is four potential users and four potential PA daemons. Usign the hooks system to *kill* the speechd-up processes could work, but it'll never allow it to *start* them unless PA is *already running*. It is this last point that is the critical one. This is why IMO it's essential to look at this from the CK side. > I'm worried that if I follow the > user instead using CK, and my logic for card access transfer does not > match PA's, then I might transfer speach while PA does not transfer > audio card access. PA relies on CK to do it so if your CK hooks are not triggered, PA wont be informed about this either and the ACLs wont be written to udev. It's pretty safe IMO to rely on CK. > We have to kill the user's speech-dispatcher and speechd-up deamons > when access to a card is transfered to a new PA instance. No you don't. PA doesn't die when the user no longer has access to a card. Even without PA, all current alsa clients are not killed when the ACLs are rewritten. PA allows the whole process to be handled gracefully, but it doesn't die. Neither should speechd-up et. al. They should just go "Oh, I'm no longer active. I'll give up control of the /dev/softsynth node and wait until I'm active again" and then basically idle until that time comes along. They could even spit out a "You user session is active again" message when they get control back. So the idea would be to start speechd-up whenever a user logs in for the first time. It will stay running until that user logs out. In the case of the gdm/idle users they are also started when the system is in that state - allowing login prompts etc. to be spoken. Of course these sessions may die off pretty quickly, but that's fine IMO. > There can > only be one speechd-up and one speech-dispatcher process at a time. I think this is broken. There should be multiple processes possible, one for each user (remember a user can login on both graphical display and tty1) in much the same way as there is one PA process per user. Only one of these processes will be active per-seat (a multi-seat system may have a mix of blind and sighted users - if two blind users are logged in to the same physical machine but at separate seats there will *need* to be two speechd-up processes running I'm not sure how that would work if there is only one /dev/softsynth system but it certainly demonstrates the need for multiple dispatchers running). > For one think, speechd-up locks the /dev/softsynth device, and the > second speechd-up wont even run. speech-dispatcher opens a port, > which speechd-up uses for communication, and multiple > speech-dispatchers conflict on the port. But, it should not be a > problem restarting these deamons as needed. If the audio card leaves, > there's no reason to have these processes hanging around. This is broken then. Multiple PA processes can be run quite happily. Each user has their own mechanism for communicating with the device via a local unix socket file (so "networking" style APIs work but without the actual networking part). This scheme is not overly original to PA, lots of systems do it (e.g. X11, GPG Agent etc.), but PA's implementation is fairly robust with protection from DoS attacks from other users by not using a fixed location inside /tmp (using /home for such special files can fail on NFS home directories as we need a local disk for tmpfs for socket files). Anyway, the whole fact that speech-dispatcher or speechd-up can only run once is something that needs fixed IMO. The multi-seat example above is one scenario where you'd want multiple versions running and the general swap between idle and real user is another scenario where it could all work nicely with multiple copies provided they played nice when the sy
Re: [pulseaudio-discuss] Accessing audio as root
Hi, Colin. I disagree that speech-dispatcher and speechd-up are broken and need to be fixed. speechd-up is a root daemon attached to the /dev/softsynth device. I see no utility in having multiple copies of it. Speech-dispatcher opens an IP port to act as a speech server over the network. It's kind of a silly feature, but why should I second-guess the speech-dispatchers developers and break it? IMO, what's broken is PA. I can't in Ubuntu get two copies running on the same machine without borking the sound system. If PA can't even do it, why should I mangle all the accessibility apps out there by making them try to follow PA's overly complex model? This has to be a screaming violation of the KISS rule. The sound system is a bit complex. Fine. To use it, you need to make all your apps complex? Really? The complexity has to be contained. It can't keep leaking out of PA into the rest of the system, making it more and more unstable as it goes. Bill On Sun, Jan 3, 2010 at 5:43 AM, Colin Guthrie wrote: > 'Twas brillig, and Bill Cox at 02/01/10 22:37 did gyre and gimble: >> This scheme sounds reasonable, though whenever someone says >> "impossible", I'm naturally inclined to give it a solid try. > > Well of course it's not impossible, suitible changes all round could > enable it. I should really have said not sensible. It's definitely not > the approach I would take. > >> Why >> would it be impossible to add PA hooks I could run when PA gains, >> uncorks, corks, or delets a connection to a card? I thought I already >> saw a system of hooks being called. > > There is a perfectly good system of hooks etc. inside PA but it all > deals with scenarios *inside a given user session*. Once the user loses > control of the sound hardware you should really think of that users PA > process going to sleep and not doing anything useful until it gets its > access back again. > > The whole problem you're trying to solve here is two fold: 1) when a > given user is not actually logged in yet and the system is idle/at gdm > login. and 2) When multiple users are logged in and we're switching > between logins. > > In all cases I'm suggesting using a user account of some sort: e.g. the > users bill and colin for the real logins and the users gdm and idle for > the login screens. This is four potential users and four potential PA > daemons. Usign the hooks system to *kill* the speechd-up processes could > work, but it'll never allow it to *start* them unless PA is *already > running*. It is this last point that is the critical one. This is why > IMO it's essential to look at this from the CK side. > >> I'm worried that if I follow the >> user instead using CK, and my logic for card access transfer does not >> match PA's, then I might transfer speach while PA does not transfer >> audio card access. > > PA relies on CK to do it so if your CK hooks are not triggered, PA wont > be informed about this either and the ACLs wont be written to udev. It's > pretty safe IMO to rely on CK. > >> We have to kill the user's speech-dispatcher and speechd-up deamons >> when access to a card is transfered to a new PA instance. > > No you don't. PA doesn't die when the user no longer has access to a > card. Even without PA, all current alsa clients are not killed when the > ACLs are rewritten. PA allows the whole process to be handled > gracefully, but it doesn't die. Neither should speechd-up et. al. They > should just go "Oh, I'm no longer active. I'll give up control of the > /dev/softsynth node and wait until I'm active again" and then basically > idle until that time comes along. They could even spit out a "You user > session is active again" message when they get control back. > > So the idea would be to start speechd-up whenever a user logs in for the > first time. It will stay running until that user logs out. > > In the case of the gdm/idle users they are also started when the system > is in that state - allowing login prompts etc. to be spoken. Of course > these sessions may die off pretty quickly, but that's fine IMO. > > >> There can >> only be one speechd-up and one speech-dispatcher process at a time. > > I think this is broken. There should be multiple processes possible, one > for each user (remember a user can login on both graphical display and > tty1) in much the same way as there is one PA process per user. Only one > of these processes will be active per-seat (a multi-seat system may have > a mix of blind and sighted users - if two blind users are logged in to > the same physical machine but at separate seats there will *need* to be > two speechd-up processes running I'm not sure how that would work if > there is only one /dev/softsynth system but it certainly demonstrates > the need for multiple dispatchers running). > >> For one think, speechd-up locks the /dev/softsynth device, and the >> second speechd-up wont even run. speech-dispatcher opens a port, >> which speechd-up uses for communication, and multiple >
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 2010-01-03 at 07:41 -0500, Bill Cox wrote: > Hi, Colin. I disagree that speech-dispatcher and speechd-up are > broken and need to be fixed. speechd-up is a root daemon attached to > the /dev/softsynth device. I see no utility in having multiple copies > of it. Speech-dispatcher opens an IP port to act as a speech server > over the network. It's kind of a silly feature, but why should I > second-guess the speech-dispatchers developers and break it? > IMO, what's broken is PA. I can't in Ubuntu get two copies running on > the same machine without borking the sound system. If PA can't even > do it, why should I mangle all the accessibility apps out there by > making them try to follow PA's overly complex model? This has to be a > screaming violation of the KISS rule. The sound system is a bit > complex. Fine. To use it, you need to make all your apps complex? > Really? > > The complexity has to be contained. It can't keep leaking out of PA > into the rest of the system, making it more and more unstable as it > goes. > > Bill IMO from what I've read so far, PA's model is "one instance per user". Whether or not its 'overly complex' depends on point-of-view, since this is the same model used by (for example) X11 and jackd. I believe that, in a multi-user system, user-space apps and services should be "one instance per user". Of course, I can see how this could be 'overly complex' from a developmental point of view, but its really a matter of the way you view your system. On the other hand, your app (speechd-up) is by its very nature a "one instance per system" app, as all apps which run as root are (should be?). Not knowing much about how it works, I can just state my belief that it won't be easy to change. So, in my simplistic and user-centric point-of-view, I wonder if speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio sink, with the appropriate modules, of course. It starts before the user logs in and only exits after the user has logged out, of course. The reasoning behind my proposal is simply that root is system-wide by definition (in my understanding), hence why all Colin's proposals have involved speechd-up running as a particular user while all your replies have mentioned root access to pulse ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Bill Cox at 03/01/10 12:41 did gyre and gimble: > Hi, Colin. I disagree that speech-dispatcher and speechd-up are > broken and need to be fixed. speechd-up is a root daemon attached to > the /dev/softsynth device. I see no utility in having multiple copies > of it. Speech-dispatcher opens an IP port to act as a speech server > over the network. It's kind of a silly feature, but why should I > second-guess the speech-dispatchers developers and break it? I think a system service that can convert plain text to speech PCM is a fair enough call, but the bit that actually outputs the sound should very much be a per-user thing. It's a per-user choice whether or not to output this (with a system-wide setting for when the system is idle - on a shared system for both blind and sighted users I'm sure the sighted users accept the need for the speech synthesis at the login stages). If this is a system wide "outputer" then it needs to have it's own preferences system built in to determin whether or not a given user wants to have the speech enabled or not. I don't think it's right that such apps have to recreate a user preferences system internally or read files in users home directories for preferences (e.g. if a user has an encrypted home dir this could cause some complications). It makes much more sense to run this bit as the user that is running the system. This is a pretty accepted approach I believe. > IMO, what's broken is PA. I can't in Ubuntu get two copies running on > the same machine without borking the sound system. If PA can't even > do it, why should I mangle all the accessibility apps out there by > making them try to follow PA's overly complex model? I think this is a problem on your setup and I've seen no evidence yet that it is PA that is at fault here (not ruling it out). I also do not think this model is overly complex. Daniel (the Ubuntu PA guy) has already said that he cannot reproduce this problem and he said he'd like to help you get it working, so I think you should accept his offer and try and work out where the problem is. > This has to be a > screaming violation of the KISS rule. The sound system is a bit > complex. Fine. To use it, you need to make all your apps complex? > Really? No. 99.9% of apps run as the user and no additional complexity is needed. This accessibility system is an exception to that rule and as a result does need to be designed properly to fit in with a modern system. The actual approach I've described is actually totally generic and pretty simple when it's boiled down. I've maybe not explained it too well. > The complexity has to be contained. It can't keep leaking out of PA > into the rest of the system, making it more and more unstable as it > goes. To be honest I think this is an overreaction due to you being very involved in this specific use case. I agree is different to what is happening now but even with the current approach there are numerous problems: 1. Different users on the system need their preferences managed by the central app, not via a simple per-user preference scheme common to 99.99% of apps. 2. Encrypted home directories could cause problems. 3. Multi-seat systems could cause problems. 4. Permissions are sub-optimally secure to allow this to work. All in all the approach I describe is much more modern and forward thinking IMO. Yes it needs apps to be updated, but then there are not many apps that are still in use today that are identical to how they were initially written 20 years ago! Everyone has got to move with the times and paradigms. 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] Accessing audio as root
'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble: > So, in my simplistic and user-centric point-of-view, I wonder if > speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio > sink, with the appropriate modules, of course. It starts before the user > logs in and only exits after the user has logged out, of course. > > The reasoning behind my proposal is simply that root is system-wide by > definition (in my understanding), hence why all Colin's proposals have > involved speechd-up running as a particular user while all your replies > have mentioned root access to pulse I guess a possibility is the following: 1. Make console-kit aware of the "idle" state as before. 2. Make the speechd-up or speech-dispatcher "headless". i.e. all they do is open a pipe (fifo) and pump their synthesised speech to it - they do not actually output audio itself. 3. Write a PA module that acts as a pulse client that opens that pipe and outputs the sound (in actual fact, we could use a combination of module-pipe-source and module-loopback for this without writing a single line of code in PA). 4. Place a script in: /usr/lib/ConsoleKit/run-session.d or /etc/ConsoleKit/run-session.d (I'm not sure which is best) which basically does the following (see /usr/bin/start-pulseaudio-x11): /usr/bin/pulseaudio --start --log-target=syslog "$@" /usr/bin/pactl load-module module-pipe-source source_name="a11y" file="/tmp/a11y.socket" > /dev/null /usr/bin/pactl load-module module-loopback source="a11y" > /dev/null (or something like the above - I could have gotten arguments wrong and you may want some channels/rate etc. stuff going on). There may also need to be something setup to stop PA from exiting after an idle timeout. With all that in place things may just work. Obviously speechd-up would have to support multiple clients opening the /tmp/a11y.socket file (and it probably shouldn't actually be in /tmp!). Does that fit better with your model of things? As a side note, would it be wise to provide some kind of positional information along with the raw PCM? I'd have thought that using stereo to good effect may help with a11y? Event sounds are already positional - those triggered at the left of the screen are much louder on the left channel etc. This is just a random thought tho'. 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] Accessing audio as root
Hi, Colin. I like your proposal, but I think I'd like to implement it in two phases. I'd like to skip step 1 for now, and not deal wit CK, but as you say, make speechd-up "headless", and write the PA modules you suggest to pipe sound from speechd-up. CK isn't working properly with PA in Ubuntu anyway, and I'd like that to get fixed first, so I can do a Vinux/Ubuntu release based on it. I want to release VInux/Ubuntu Lucid in May, and there's a ton of non-PA related work to do, so for now, I'll stick to what I can get working quickly. Please don't be mad at me if I do one release with PA running as a system daemon. However, for the following release, I'd like to get it "right". Speechd-up isn't the only "root" level sound source that's out there. Espeakup is another alternative to speechd-up which is currently much more popular, but limited in that it can only use the espeak voice. >From the point of view of developers for such packages, they just want to write to a sound output interface. Espeakup uses portaudio, and frankly, I don't want to rewrite that interface (one is enough for me). These processes, even speechd-up, set custom buffering parameters in PA (speechd-up requires the tlength paramter to be much shorter than default). Instead of writing modules for PA to talk directly to speechd-up, why not write modules to allow user-land PA instances to read from a special global PA instance? That would simplify life for the root level sound packages greatly, and keep control of the interaction entirely within PA code. What do you think? Also, thanks a ton, Colin, for all the advice! Bill On Sun, Jan 3, 2010 at 9:21 AM, Colin Guthrie wrote: > 'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble: >> So, in my simplistic and user-centric point-of-view, I wonder if >> speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio >> sink, with the appropriate modules, of course. It starts before the user >> logs in and only exits after the user has logged out, of course. >> >> The reasoning behind my proposal is simply that root is system-wide by >> definition (in my understanding), hence why all Colin's proposals have >> involved speechd-up running as a particular user while all your replies >> have mentioned root access to pulse > > > I guess a possibility is the following: > > 1. Make console-kit aware of the "idle" state as before. > 2. Make the speechd-up or speech-dispatcher "headless". i.e. all they do > is open a pipe (fifo) and pump their synthesised speech to it - they do > not actually output audio itself. > 3. Write a PA module that acts as a pulse client that opens that pipe > and outputs the sound (in actual fact, we could use a combination of > module-pipe-source and module-loopback for this without writing a single > line of code in PA). > 4. Place a script in: > /usr/lib/ConsoleKit/run-session.d > or > /etc/ConsoleKit/run-session.d > (I'm not sure which is best) > which basically does the following (see /usr/bin/start-pulseaudio-x11): > > /usr/bin/pulseaudio --start --log-target=syslog "$@" > /usr/bin/pactl load-module module-pipe-source source_name="a11y" > file="/tmp/a11y.socket" > /dev/null > /usr/bin/pactl load-module module-loopback source="a11y" > /dev/null > > > (or something like the above - I could have gotten arguments wrong and > you may want some channels/rate etc. stuff going on). There may also > need to be something setup to stop PA from exiting after an idle timeout. > > > With all that in place things may just work. Obviously speechd-up would > have to support multiple clients opening the /tmp/a11y.socket file (and > it probably shouldn't actually be in /tmp!). > > Does that fit better with your model of things? > > > As a side note, would it be wise to provide some kind of positional > information along with the raw PCM? I'd have thought that using stereo > to good effect may help with a11y? Event sounds are already positional - > those triggered at the left of the screen are much louder on the left > channel etc. This is just a random thought tho'. > > 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] Accessing audio as root
'Twas brillig, and Bill Cox at 03/01/10 16:23 did gyre and gimble: > Speechd-up isn't the only "root" level sound source that's out there. > Espeakup is another alternative to speechd-up which is currently much > more popular, but limited in that it can only use the espeak voice. > From the point of view of developers for such packages, they just want > to write to a sound output interface. Espeakup uses portaudio, and > frankly, I don't want to rewrite that interface (one is enough for > me). These processes, even speechd-up, set custom buffering > parameters in PA (speechd-up requires the tlength paramter to be much > shorter than default). Well in the situation I'm proposing, the speechd-up would actually just write it's audio to a pipe (totally bypassing pulse client API), and it would be up to module-pipe-source and module-loopback to act as the pulse client, reading from the pipe and actually doing the output. The buffering metrics can be somewhat adjusted when loading module-loopback. > Instead of writing modules for PA to talk > directly to speechd-up, Well it wouldn't be specific modules, just using module-pipe-source which already exists. It's just a matter of writing to the chosen pipe in a known format. > why not write modules to allow user-land PA > instances to read from a special global PA instance? That would > simplify life for the root level sound packages greatly, and keep > control of the interaction entirely within PA code. In principle this is not too bad an idea, but I'm really not sure of the implications of this. I guess some sort of system level PA that is triggered from system dbus or similar could work and still allow the use of some of the PA client libraries. The client would have to specifically ask for access to this and I'm still not sure of the overall security model here. All of the suggestions in this thread are pretty "out there" anyway and I'd really like to get some feedback from others (especially Lennart) on the most desirable approach. I think he's heading home soon, so should catch up on the backlog in due course! > Also, thanks a ton, Colin, for all the advice! I tries me best :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] Accessing audio as root
Hi, On So, Dez 27, 2009 at 01:34:46 +0100, Lennart Poettering wrote: > On Sat, 26.12.09 08:31, Halim Sahin (halim.sa...@freenet.de) wrote: > > > > > > Lennart > > > > > > > > > I believe in his particular use-case he's concerned about the > > > > screenreader prior to the DE starting up (boot messages and the like?). > > > > > > We actually cover that inside of gdm, where you can get access to the > > > boot messages. > > > > Ok what about consolescreenreaders like sbl brltty or speakup? > > They need a working audiosystem to provide > > usefull stuff before login or to read the login pprompt. > > The gdm login screen should be prefectly accessible. I am talking about mixed setups between gdm+gnome and a plain bash textconsole! > > With pulseaudio I need to login without feedback, start the speech server > > and > > then restart the screenreader. > > Use gdm! Siehe oben. > > By design mac and windows are not comparable with linux > > because they are not a multi user OS. > > That is simply not true. ??? > > For german users: > > http://www.stud.uni-hannover.de/stud/unix-ag-bhb/node27.html > > > > changing the unix behaviour is the main problem here. > > Maybe you don't need this but others do. > > Unix is pretty much a broken system. It might be a useful base and > more useful as a base than other systems, but uh, of course we need to > deviate from a system that was designed 40 years ago. People who think > that Unix is a flawless system and every depature from it would be bad > are just incredibly naive. Sorry I want to be able to use my computer (wich isn't possible) if all distros are integrating pulse (like your suggestions). > > It should be possible to use the audiosystem the (old way). > > You are always welcome to use a distribution from 3 years ago if you > feel that progress is not for you... Thanks a lot for your understanding. I will suggest all blind people to use debian lenny or similar :-(. Read the whole thread and see what happens: All suggestions are producing more complex apps and only pa doesn't need to be changed. Here are my thoughts about pulse: Ok This will my last post in this thread ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Ng Oon-Ee wrote: >On Sun, 2010-01-03 at 07:41 -0500, Bill Cox wrote: >> Hi, Colin. I disagree that speech-dispatcher and speechd-up are >> broken and need to be fixed. speechd-up is a root daemon attached to >> the /dev/softsynth device. I see no utility in having multiple copies >> of it. Speech-dispatcher opens an IP port to act as a speech server >> over the network. It's kind of a silly feature, but why should I >> second-guess the speech-dispatchers developers and break it? >> >> IMO, what's broken is PA. I can't in Ubuntu get two copies running on >> the same machine without borking the sound system. If PA can't even >> do it, why should I mangle all the accessibility apps out there by >> making them try to follow PA's overly complex model? This has to be a >> screaming violation of the KISS rule. The sound system is a bit >> complex. Fine. To use it, you need to make all your apps complex? >> Really? >> >> The complexity has to be contained. It can't keep leaking out of PA >> into the rest of the system, making it more and more unstable as it >> goes. >> >> Bill > >IMO from what I've read so far, PA's model is "one instance per user". >Whether or not its 'overly complex' depends on point-of-view, since this >is the same model used by (for example) X11 and jackd. I believe that, >in a multi-user system, user-space apps and services should be "one >instance per user". Of course, I can see how this could be 'overly >complex' from a developmental point of view, but its really a matter of >the way you view your system. > >On the other hand, your app (speechd-up) is by its very nature a "one >instance per system" app, as all apps which run as root are (should >be?). Not knowing much about how it works, I can just state my belief >that it won't be easy to change. > >So, in my simplistic and user-centric point-of-view, I wonder if >speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio >sink, with the appropriate modules, of course. It starts before the user >logs in and only exits after the user has logged out, of course. > >The reasoning behind my proposal is simply that root is system-wide by >definition (in my understanding), hence why all Colin's proposals have >involved speechd-up running as a particular user while all your replies >have mentioned root access to pulse Regardless, this problem for the visually impaired is one that needs to be addressed ASAP before we have a whole battalion of lawyers from the ACLU challenging us all in courts that we don't, by the very nature of linux, have the funds to defend against. So IMNSHO, it is something that must be done, and damn the reasons for architecting PA the way it currently is. It really is that simple. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) *** *** * ** Confucius say: "Is stuffy inside fortune cookie." *** *** ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Colin Guthrie wrote: >'Twas brillig, and Ng Oon-Ee at 03/01/10 13:26 did gyre and gimble: >> So, in my simplistic and user-centric point-of-view, I wonder if >> speechd-up accepts audio INPUTS? Perhaps it could act as a pulseaudio >> sink, with the appropriate modules, of course. It starts before the user >> logs in and only exits after the user has logged out, of course. >> >> The reasoning behind my proposal is simply that root is system-wide by >> definition (in my understanding), hence why all Colin's proposals have >> involved speechd-up running as a particular user while all your replies >> have mentioned root access to pulse > >I guess a possibility is the following: > >1. Make console-kit aware of the "idle" state as before. >2. Make the speechd-up or speech-dispatcher "headless". i.e. all they do >is open a pipe (fifo) and pump their synthesised speech to it - they do >not actually output audio itself. >3. Write a PA module that acts as a pulse client that opens that pipe >and outputs the sound (in actual fact, we could use a combination of >module-pipe-source and module-loopback for this without writing a single >line of code in PA). >4. Place a script in: >/usr/lib/ConsoleKit/run-session.d > or >/etc/ConsoleKit/run-session.d >(I'm not sure which is best) >which basically does the following (see /usr/bin/start-pulseaudio-x11): > >/usr/bin/pulseaudio --start --log-target=syslog "$@" >/usr/bin/pactl load-module module-pipe-source source_name="a11y" >file="/tmp/a11y.socket" > /dev/null >/usr/bin/pactl load-module module-loopback source="a11y" > /dev/null > > >(or something like the above - I could have gotten arguments wrong and >you may want some channels/rate etc. stuff going on). There may also >need to be something setup to stop PA from exiting after an idle timeout. > > >With all that in place things may just work. Obviously speechd-up would >have to support multiple clients opening the /tmp/a11y.socket file (and >it probably shouldn't actually be in /tmp!). > >Does that fit better with your model of things? > > >As a side note, would it be wise to provide some kind of positional >information along with the raw PCM? I'd have thought that using stereo >to good effect may help with a11y? Event sounds are already positional - >those triggered at the left of the screen are much louder on the left >channel etc. This is just a random thought tho'. > >Col > And it seem like a doable, sane approach to the problem. A voice of sanity midst the riot this could become. But that still leaves PA's biggest problem for this user: It picks the most obviously wrong choice in available audio outputs, whether they exist or not in the hardware (in my case they don't physically exist), and I have not found a way around that yet. A default install of mdv2010 on another drive here is silent, the only thing heard when booting it is the thump in the speakers as udev starts & loads emu10k1. There needs to be a 'blacklist' that is capable of making it ignore the audio it finds during boot initialization that is known not to work. And this needs to be a system wide setting that we set once and can then forget. The only choice, it seems, for those of us with such hardware, is to disable PA by whatever means it takes so alsa can then make use of the hardware it knows works. So we do. And this choice is forced on us by the distros who make it the default, and PA's refusal to ack that a problem exists or make any visible efforts to fix it. That is a strong accusation, but from this users vantage point, we have no choice but to come to that conclusion. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I couldn't remember when I had been so disappointed. Except perhaps the time I found out that M&Ms really DO melt in your hand. -- Peter Oakley ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, Jan 3, 2010 at 12:39 PM, Halim Sahin wrote: > Here are my thoughts about pulse: > Ok This will my last post in this thread I can put in a good word for Halim. He's been very helpful in the last several weeks working out issues with Orca and the back end sound system. Any good effort to support accessibility needs to include guys like Halim. If Halim is frustrated, that's a bad sign. Bill ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
I've removed gdm from my Lucid system, after Tony Sales (founder/driver of Vinux) suggested it. I'm already feeling rather attached to my gdm-less system. It now boots into a very nicely talking console login prompt. I just login, do whatever I like on the console, and type 'startx' if I want Firefox or other graphical applications. I'll make this commitment to the devs of PA: If you support me (I shouldn't require much) in getting Vinux/Ubuntu Lucid working with PA in system-wide daemon mode, I will work hard to make sure the next release is done the "right" way. Of course, the details of the "right" way still need to be worked out, given that we need to process speech coming from the /dev/softsynth kernel module. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 2010-01-03 at 12:29 -0500, Gene Heskett wrote: > > Regardless, this problem for the visually impaired is one that needs to be > addressed ASAP before we have a whole battalion of lawyers from the ACLU > challenging us all in courts that we don't, by the very nature of linux, have > the funds to defend against. > > So IMNSHO, it is something that must be done, and damn the reasons for > architecting PA the way it currently is. > > It really is that simple. > Maybe I don't have context here, not being from the good ol' USA and all, but is this in any way, shape, or form likely? You know, the whole idea of being sued for the stuff you give away for free not being equal access? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, 2010-01-03 at 13:57 -0500, Bill Cox wrote: > I've removed gdm from my Lucid system, after Tony Sales > (founder/driver of Vinux) suggested it. I'm already feeling rather > attached to my gdm-less system. It now boots into a very nicely > talking console login prompt. I just login, do whatever I like on the > console, and type 'startx' if I want Firefox or other graphical > applications. > > I'll make this commitment to the devs of PA: If you support me (I > shouldn't require much) in getting Vinux/Ubuntu Lucid working with PA > in system-wide daemon mode, I will work hard to make sure the next > release is done the "right" way. Of course, the details of the > "right" way still need to be worked out, given that we need to process > speech coming from the /dev/softsynth kernel module. In my understanding it really doesn't require much, just copying some key-file somewhere and running pulse with --system. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Gene Heskett at 03/01/10 17:48 did gyre and gimble: > And it seem like a doable, sane approach to the problem. A voice of sanity > midst the riot this could become. :) > But that still leaves PA's biggest problem for this user: It picks the most > obviously wrong choice in available audio outputs, whether they exist or not > in the hardware (in my case they don't physically exist), and I have not > found a way around that yet. A default install of mdv2010 on another drive > here is silent, the only thing heard when booting it is the thump in the > speakers as udev starts & loads emu10k1. I'm a bit confused bu your mail to be honest. Can you explain what you meant a bit about which of your devices it's choosing? Do you have multiple sound cards? pacmd ls output would be good. 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] Accessing audio as root
On Sunday 03 January 2010, Colin Guthrie wrote: >'Twas brillig, and Gene Heskett at 03/01/10 17:48 did gyre and gimble: >> And it seem like a doable, sane approach to the problem. A voice of >> sanity midst the riot this could become. >> >:) >: >> But that still leaves PA's biggest problem for this user: It picks the >> most obviously wrong choice in available audio outputs, whether they >> exist or not in the hardware (in my case they don't physically exist), >> and I have not found a way around that yet. A default install of mdv2010 >> on another drive here is silent, the only thing heard when booting it is >> the thump in the speakers as udev starts & loads emu10k1. > >I'm a bit confused bu your mail to be honest. Can you explain what you >meant a bit about which of your devices it's choosing? Do you have >multiple sound cards? > Colin, I have posted several times about this, and usually simply ignored. And yesm there are, according to the bus scanning done at bootup, 3 separate audio systems in this machine. 1. There is an intel-hd or whatever its called, claim from my video card that has no connection to the physical world that I can find, on my rv610 chipset based video card. 2. There is another intelhd chipset on the mother board that I suppose might be able to make a few pitiful squeaks should I ever plug any amps & speakers into it, and before PA, I was able to dedicate it for use by skype, but not since PA arrived. 3. I have a 24 bit Audigy2 Value with about 64 i/o's that I use for everything because it never runs out of headroom. >pacmd ls output would be good. [r...@coyote etc]# pacmd ls E: pacmd.c: No PulseAudio daemon running However, from an lspci -v: 01:07.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value Subsystem: Creative Labs Device 1001 Flags: bus master, medium devsel, latency 32, IRQ 17 I/O ports at 9c00 [size=64] Capabilities: [dc] Power Management version 2 Kernel driver in use: EMU10K1_Audigy Kernel modules: snd-emu10k1 [...] 03:00.1 Audio device: ATI Technologies Inc RV610 audio device [Radeon HD 2400 PRO] Subsystem: Diamond Multimedia Systems Device aa10 Flags: bus master, fast devsel, latency 0, IRQ 11 Memory at fddfc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable- Capabilities: [100] Vendor Specific Information The motherboard audio system is not found specifically because I build my own kernels (currently running 2.6.32 final) and do not build its driver, therefore simplifying the problem at the expense of losing skype, and that is a shrug, as it's just a toy to annoy verizon with anyway. I do that on general principles anyway. :-) And when booted to mdv2010-x64, PA picks the video card device & I've used every pa utility I could find to try and get it away from the 2nd device above and bring some audio back to life, with no apparent effect. Also, booted to mdv-2010-x64, the only place I can see the Audigy card is in lspci and possibly dmesg. PA's tools can't find it. >Col > I'll reboot and see what I find & report shortly. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) For every credibility gap, there is a gullibility fill. -- R. Clopton ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
'Twas brillig, and Gene Heskett at 03/01/10 21:48 did gyre and gimble: > And yesm there are, according to the bus scanning done at bootup, 3 separate > audio systems in this machine. > > 1. There is an intel-hd or whatever its called, claim from my video card > that has no connection to the physical world that I can find, on my rv610 > chipset based video card. Presumably an HDMI device. > 2. There is another intelhd chipset on the mother board that I suppose might > be able to make a few pitiful squeaks should I ever plug any amps & speakers > into it, and before PA, I was able to dedicate it for use by skype, but not > since PA arrived. Strange that this is not possible anymore. You should be able to set an "Off" profile in pavucontrol's Configuration tab to have pulseaudio ignore any given card and use it for what you like. I presume this is an Intel HDA card. I have a similar card here and it works very well with pulse but the HDA range is really more of a specification than a particular device and there are numerous small variations and a whole bunch of quirks in ALSA to deal with it. Strange that it only has a few squeaks tho'. Is this with Glitch Free mode disabled in draksound? > 3. I have a 24 bit Audigy2 Value with about 64 i/o's that I use for > everything because it never runs out of headroom. Yeah creative cards can be problematic due to their lack of support for the more advanced way PA drives the hardware. >> pacmd ls output would be good. > > [r...@coyote etc]# pacmd ls > E: pacmd.c: No PulseAudio daemon running OK, let me clarify: pacmd ls output *while pulseaudio is running* would be good. > And when booted to mdv2010-x64, PA picks the video card device & I've used > every pa utility I could find to try and get it away from the 2nd device > above and bring some audio back to life, with no apparent effect. Also, > booted to mdv-2010-x64, the only place I can see the Audigy card is in lspci > and possibly dmesg. PA's tools can't find it. It should detect the Audigy 2 card even if it doesn't work fantastically in glitch free mode. HDMI cards should be prioritised below PCI cards in the internal priority list so it should never be the default if other cards are detected. The pacmd ls output should be telling. Also, if you can post the pulseaudio - output too that would be useful. Can you start a new thread for this? 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] Accessing audio as root
No, this is extremely unlikely, and nothing to worry about. Lawyers in the USA only sue people with money. Bill On Sun, Jan 3, 2010 at 3:41 PM, Ng Oon-Ee wrote: > Maybe I don't have context here, not being from the good ol' USA and > all, but is this in any way, shape, or form likely? You know, the whole > idea of being sued for the stuff you give away for free not being equal > access? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sun, Jan 3, 2010 at 4:48 PM, Gene Heskett wrote: > 01:07.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value > Subsystem: Creative Labs Device 1001 > Flags: bus master, medium devsel, latency 32, IRQ 17 > I/O ports at 9c00 [size=64] > Capabilities: [dc] Power Management version 2 > Kernel driver in use: EMU10K1_Audigy > Kernel modules: snd-emu10k1 If this device isn't audible with speaker-test -Dplug:front:Audigy2 -twav -c2 -l1 (substitute "Audigy2" with whatever corresponds from cat /proc/asound/cards), then my guess is that you're experiencing one of the many quirks of the Live and Audigy families where you need to toggle the Analog/Digital Output control. Tritech and Sigmatel both screwed up big time with no way to differentiate between codec revisions that require it to be unmuted (vice those that require it to be *muted*) for audible analog playback. But, as Colin recommended, that would be a separate thread. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Ng Oon-Ee wrote: >On Sun, 2010-01-03 at 12:29 -0500, Gene Heskett wrote: >> Regardless, this problem for the visually impaired is one that needs to >> be addressed ASAP before we have a whole battalion of lawyers from the >> ACLU challenging us all in courts that we don't, by the very nature of >> linux, have the funds to defend against. >> >> So IMNSHO, it is something that must be done, and damn the reasons for >> architecting PA the way it currently is. >> >> It really is that simple. > >Maybe I don't have context here, not being from the good ol' USA and >all, Since this particular distro is US based, and traded on the NYSE these days... >but is this in any way, shape, or form likely? You know, the whole >idea of being sued for the stuff you give away for free not being equal >access? While I doubt if anybody except the ACLU might get involved, the possibility certainly exists, particularly if a member of that group is adversely effected by this perceived lack. And they are pit bulls when they decide something needs addressing. 'Free' will have nothing to do with it. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Every man is as God made him, ay, and often worse. -- Miguel de Cervantes ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Accessing audio as root
On Sunday 03 January 2010, Bill Cox wrote: >No, this is extremely unlikely, and nothing to worry about. Lawyers >in the USA only sue people with money. > >Bill Chuckle back at ya Bill, and you are probably right. But the word probably still bothers me. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yevtushenko has... an ego that can crack crystal at a distance of twenty feet. -- John Cheever ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
