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

Re: pulseaudio causing crashing of applications



Lennart Poettering wrote:

Lennart Poettering <mzerqung <at> 0pointer.de> writes:
This is somewhat expected behaviour. Access to the audio device
follows the active session on the display. I.e. if you switch VTs than
ConsoleKit+HAL will change the ACLs of the audio devices and tell PA
to stop accessing the audio device. This will cause playback to pause
for all applications accessing PA. However, as soon as you switch back
the session, the playback should continue. This is not perfect
however, since we don't inform Gst/Rhyhtmbox that the audio device is
temporarily stopped (there's no way to do that afaik).
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 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.

--
  Les Mikesell
   lesmikesell gmail com


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