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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
