'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
