pulseaudio causing crashing of applications

Les Mikesell lesmikesell at gmail.com
Fri Feb 15 20:20:39 UTC 2008


Jeff Spaleta wrote:
> On Fri, Feb 15, 2008 at 10:17 AM, Alan Cox <alan at redhat.com> wrote:
>>  But its set by policy files so if you want other users to broadcast your
>>  webcam over the internet all day, listen to all your calls and send them to
>>  friends you can configure it that way, but that should not be the default.
> 
> 
> Again... it comes back to the fact that people are resisting learning
> how to write Hal/ConsoleKit policy to meet their local needs.
>

How can you resist (or consider) learning something when there's not 
even a mechanism exposed to interface with it?

But my concern at this point isn't with the details of 'how' to make the 
change I'd want, it is whether it will be possible at all in the likely 
scenarios.   For example, I normally use a USB sound device on another 
OS and need the ability to switch between that and an on-board device. 
Now, if one user is actively using the USB device (which in my case 
would be connected to a receiver/speakers playing for the whole room), 
does another login session automatically kill access even if I did want 
it to kill access to the onboard device with its smaller nearby 
speakers?  What if the USB device in question is a new one, plugged in 
after the ConsoleKit policy is written - or there is more than one? 
Also, if I were to use the phone connection that you are so worried 
about, I'd almost certainly want it to work through bluetooth, again 
probably through a USB adapter that may not be known at policy-writing 
time.  Will this scheme permit 'my' associated bluetooth device to 
continue working with my session or is it going to give ownership to 
someone who logs in mid-call to check their email?   Does the policy 
scheme have sufficient understanding of multiple and potentially 
unknown/hotplugged devices and on-the-fly associations to do anything 
sensible with them?

-- 
   Les Mikesell
     lesmikesell at gmail.com




More information about the fedora-devel-list mailing list