[pulseaudio-discuss] Using pulseaudio with speakup

[Ng Oon-Ee]

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...)