On Sat, 2010-01-02 at 14:31 +0100, Markus Rechberger wrote: > On Sat, Jan 2, 2010 at 2:17 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote: > > 'Twas brillig, and Bill Cox at 01/01/10 21:58 did gyre and gimble: > >> However, even with these changes, there are bugs due to pulseaudio's > >> user-based structure. Today, in Karmic, if I 'switch user' to another > >> use, my new gnome session has no sound. That's because there are two > >> pulseaudio processes running, and the first one takes over control of > >> the sound card and does not share. > > > > Other folk have replied now but just to explain in detail for clarity: > > > > It is by design that multiple pulseaudio processes run at the same time > > but the idea is that they gracefully drop access to the actual sound > > hardware when the given user is not supposed to have access. This is why > > the gdm user has direct access at the login window and then when a user > > logs in it gracefully hands control over to the real user. Again > > switching users should all just work. > > > > PA should remain running even when the user does not have current access > > to the hardware as it will "cork" it's streams (a sort of equivalent to > > pause) and as more applications are aware of the concept of corking they > > will be able to adjust their UI accordingly. We can also issue corks for > > other reasons (e.g. a voip call comes in so the music and video apps are > > corked/paused. > > In practice did you test this with some mpeg players? I wonder if they > will automatically pause the > Video. Video is usually synced against audio as you might know. > It should not make any problem with mpeg videos but how about live video. > Unless the application starts to timeshift by itself PA will take care > that the livestream will become corrupted. > Does this corking mechanism really just pause the readout of the > audiosamples? - I see quite some problems if > it does so. > > Markus On my system (non-live video) the video does indeed stop alongside the audio. This was using Gnome Mplayer, I believe VLC does the same too (but can't recall ever having done it while using VLC due to VLC's prone-ness to crashing on my setup). With live video I suppose the responsibility is the users to ensure nothing else takes control of the sound card (a situation which must involve user-input anyhow, like starting Jack or changing configurations...)
