[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

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 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]