Re: [pulseaudio-discuss] no clue how to downsample network audio stream + some minor issues
Hi, 'Twas brillig, and vitaminx at 26/11/09 03:27 did gyre and gimble: I'm pretty new to pulseaudio and after some days of reading manuals i'm actually stuck with 3 things: - i have a media server running pulseaudio and i want to stream audio to it. works pretty well so far, but my bandwidth is quite low for the moment so i want to downsample the sound *only* when i use the tunnel sink. i'm stuck here, i don't know where to configure that. daemon.conf (default-sample-rate) doesn't seem to be the right place because it resamples the sound locally as well - what i don't want. See http://pulseaudio.org/wiki/Modules#DeviceDrivers The module-tunnel-sink module should take a rate= argument. There is no GUI tool to configure this, but if you enable it via paprefs, you can hack it into the mix using gconf-editor (for now at least - I am intending on changing this eventually). FWIW, some kind of tunnel compression technology has been mooted in the past and will likely eventually make it's way into PA, but there are several other things that are further up the priority list, so I wouldn't hold your breath for too long! :p - using alsamixer i'm getting a new pulseaudio device by default. that's cool - i thought - so i could map my multimedia keys to amixer to control the volumes... with no success, because alsamixer shows me the volume bar but it doesn't let me change it. why is that and can i enable it somehow? You can use it, but you have to use the numbers 0-9... for some unknown reason (read: no ones really be bothered enough to seriously look) the arrow keys don't work! amixer set Master +10% Should get your your volume adjustment. HTH 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] hang when trying to drain empty stream
'Twas brillig, and Gregory Petrosyan at 25/11/09 21:34 did gyre and gimble: On Thu, Nov 19, 2009 at 9:54 PM, Gregory Petrosyan gregory.petros...@gmail.com wrote: I believe there is a bug in PA: when trying to drain empty stream (newly created, or just after pa_stream_flush()) returned pa_operation never completes. Because it's not possible to know in advance if a stream is empty, IMO pa_stream_drain should succeed ASAP when called on empty stream, and not hang. Hey, a week has passed, and the bug is still alive! Sorry, the main guy who could answer this is currently on holidays. Please push a bug into Trac so that it's not lost among the many emails when he returns. I'm not sure I know enough about this side of things to comment in any useful way (on the surface of your description I'm tending to agree with your but I don't know the implications! 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] Why no 'default device' option?
'Twas brillig, and Jeremy Nickurak at 25/11/09 20:37 did gyre and gimble: On Wed, Nov 25, 2009 at 11:48, Colin Guthrie gm...@colin.guthr.ie mailto:gm...@colin.guthr.ie wrote: PA will always remember what your app has chosen. So if you play something with an app for the very first time, it is assigned to the fallback device (we know no better). Is this the case even if you don't manually select one? Ie, the first time it's used, it uses the fallback device. The second time, does it still go to the fallback, or does it go to the same device it fell-back to last time? I'm hoping it's the former, in which case... what is the difference between a fall-back device and a default-device? Well, there is a save_sink flag we set when we are supposed to save the sink... it's a little confusing and I've not fully groked the code, but it should only be set when the user has specifically moved the stream. However, I'm not 100% sure that is the case right now. I'd have to look at the code to answer 100% here, but certainly the intention is that the sink is only saved if the user has actively moved the sink (e.g. calls the appropriate API command). 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] Why no 'default device' option?
'Twas brillig, and Daniel Chen at 25/11/09 19:50 did gyre and gimble: On Wed, Nov 25, 2009 at 12:14 PM, Vadim Peretokin vpereto...@gmail.com wrote: Currently with PulseAudio, every new app that I start will use the onboard sound card. I have to manually go to pavucontrol, and change the streams to my headset The new gnome-volume-control applet shipped in 2.28 works just fine for this use case. I know at least it works in Fedora 12 and Ubuntu 9.10 running 0.9.21, having just tested each on a different machine both with internal audio and a usb audio device. Yeah (I meant to mention this in my reply too but forgot!). The g-v-c system will actually update the stream-restore database in PA to rewrite the previously stored devices. This is the critical difference between it and pavucontrol in terms of the defaults. Personally I find it all rather clunky and would like to see more robust handling inside PA in this regard. 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] Accessing audio as root
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... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Why no 'default device' option?
On Thu, 2009-11-26 at 08:42 +, Colin Guthrie wrote: 'Twas brillig, and Jeremy Nickurak at 25/11/09 20:37 did gyre and gimble: On Wed, Nov 25, 2009 at 11:48, Colin Guthrie gm...@colin.guthr.ie mailto:gm...@colin.guthr.ie wrote: PA will always remember what your app has chosen. So if you play something with an app for the very first time, it is assigned to the fallback device (we know no better). Is this the case even if you don't manually select one? Ie, the first time it's used, it uses the fallback device. The second time, does it still go to the fallback, or does it go to the same device it fell-back to last time? I'm hoping it's the former, in which case... what is the difference between a fall-back device and a default-device? Well, there is a save_sink flag we set when we are supposed to save the sink... it's a little confusing and I've not fully groked the code, but it should only be set when the user has specifically moved the stream. However, I'm not 100% sure that is the case right now. I'd have to look at the code to answer 100% here, but certainly the intention is that the sink is only saved if the user has actively moved the sink (e.g. calls the appropriate API command). Col I can confirm that on my setup (0.9.19) the sink for an app (take mpd for example) is only saved if I manually move it. So say I have on-board sound and a BT headset connected, I move the mpd output to the BT headset. Then I disconnect the BT headset and the mpd output falls back to on-board. Even if I restart PA/the machine repeatedly, as long as I don't specifically assign the mpd output to any other sink, as soon as connect my BT headset it moves to the BT sink. ___ 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 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 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. 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] hang when trying to drain empty stream
On Thu, Nov 26, 2009 at 11:44 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Please push a bug into Trac so that it's not lost among the many emails when he returns. Already there -- http://pulseaudio.org/ticket/725 Gregory ___ 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 mrechber...@gmail.com 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 seven.st...@gmail.com wrote: On Thu, Nov 26, 2009 at 4:54 AM, Markus Rechberger mrechber...@gmail.com 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 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. 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 gm...@colin.guthr.ie 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
'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 gm...@colin.guthr.ie 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 with OSS and Alsa by default). Markus ___ pulseaudio-discuss
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 mrechber...@gmail.com wrote: On Fri, Nov 27, 2009 at 7:02 AM, Colin Guthrie gm...@colin.guthr.ie 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
