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

Re: pulseaudio causing crashing of applications



On Wed, 13.02.08 12:33, Les Mikesell (lesmikesell gmail com) wrote:

>>> Have you considered just muting the sound rather than blocking the 
>>> applications? The obvious drawback is that the user doesn't automatically 
>>> get back to where he/she left, but on the other hand, you can't really 
>>> expect sound applications to know how to handle a blocked sound device, 
>>> and it is also application-specific whether returning to where you left 
>>> is a good or bad idea (think of a live stream, for example: in that case, 
>>> returning to where you left might not even be possible, and if it is, 
>>> it's usually not what the user wants).
>> It's a bit difficult to continue streaming audio based on the sound
>> cards clock if you don't have access to the sound card anymore.
>
> Does this mean you should always use Xnest, NX client, vnc, ssh, etc, 
> instead of VTs to get login sessions that don't accidentally grab
> unrelated 

"accidentaly"? "unrelated"?  The whole point of CK is that we change
ownership of *related* devices, i.e. those directly attached to the
seat in some way.

> hardware ownership?  That seems backwards if what you really want is an 
> audio player as a server that isn't tied to a particular login session.

Hmm, I think we had this discussion multiple times already on this
ML...

You can always change the HAL/CK policy to not limited access to audio
devices to the current session. The default however is that only the
active user session can access the device.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4


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