[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: how is pulseaudio supposed to work?



Lennart Poettering wrote:

Footnotes:

[1] And I certainly don't want other people using my machine to spy on
    my VoIP calls or listen into the audio track of my very private
    porn videos! ;-)

But sometimes you do want simultaneous multiplexed access or random use among a set of users/processes not separated by any particular event. It should be the administrator/users decision about who can do what, not hard coded in a program. Controlling access among multiple users on a multi user operating system isn't exactly a new concept except for the recent notion that logging in at the console (if you happen to have such a thing) should magically give you ownship of more than /dev/tty. Why can't you provide an init.d script to be used (optionally) to start a daemon associated with a local sound device if you need it to handle processes not associated with a login (perhaps mythtv or any of the jukebox server process), add a group that will always be permitted access so certain users/processes can be given permanent access regardless of any events, and use kernel locking if you want to guarantee exclusive access? That makes it the usual 'service service_name start/stop' and 'chkconfig service_name on' operations that fedora/RH users expect to use to control optional daemons. If sessions that proxy to remote devices run separate daemons, those could still be started on demand, and if you don't need the init.d daemon, you wouldn't have to use it.

--
  Les Mikesell
   lesmikesell gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]