[pulseaudio-discuss] Pulseaudio as a systemwide deamon and as the default ALSA plugin doesn't seem to work right.... ?

[Kevin Williams]

Thanks a lot for the detailed response. I really appreciate it.

On November 19, 2007 09:58:37 pm Lennart Poettering wrote:
> My educated guess is that some of your apps use PA natively, others
> don't but hardcode are configured to use the raw ALSA devices, or raw
> OSS devices. Now, PA closes all devices after a short time of
> idle. So, what might happen to you is that you first use a native
> app. That causes PA top open the device. If you then use a non-native
> app, then it won't work.  But after the idleness timeout it will
> suddenly and magically start to work, because PA closed the devices.

Voila ! That explains the weird behaviour seen with all the apps. But, if the 
option "exit-idle-time" is responsible then, I don't have it set in 
daemon.conf !

> If you use PA this way then local authentication works by membership
> in the group pulse-rt. What you described sounds like authentication
> errors. So please make sure that all users who try to access PA are in
> that group.

> Oops, that group is "pulse-access", not "pulse-rt". Sorry for the
> confusion.

 You almost got me there ! I really thought this was something new, not 
mentioned anywhere in the docs ! :-)

Yes, I'd set up my user account to be a member of the group pulse-access and 
hence, I wouldn't think of them as access errors. You explanation above, 
about pulse acquiring the resources and relinquishing them after a predefined 
period has elapsed explains it, save the 'exit-idle-time' part.

As I mentioned in my previous mail things were working just perfect by having 
pulseaudio launch as per user daemon. I didn't until today realized the fact 
that the script I've written to automatically launch pulseaudio as per user 
daemon by kdm, was actually launching pulseaudio as the root user !! SO, 
pulseaudio was being launched as root user daemon without the '--system' 
switch but with, '-D' switch ! 

Now that, I've set it right, pulseaudio launches by the user logging in. 
That's the best part. What's annoying is error messages are back only a bit 
different this time. These messages seem to be limited to xine and xine 
dependent apps like amarok, kaffeine etc & appear when I hit next/previous on 
amarok. Other apps not dependent on xine seemingly are running well. No error 
messages so far.

The error message I get is "Audio output unavailable. The device is busy. Xine 
engine parameter:    ". 
After a while, the error message changes to "xine was unable to 
initialize any audio drivers" !!

Any ideas ?

Thanks,

Kevin

		
> On Thu, 15.11.07 11:59, Kevin Williams (kevkim55 at gmail.com) wrote:
> > On November 15, 2007 06:17:07 am Diego 'Flameeyes' Pettenò wrote:
> > > This sounds like a message coming from xine, or at least it is quite
> > > similar from the xine message expressing the same problem. If this is
> > > the case, make sure that you're not using hw:0 as device in the xine
> > > configuration; ideally you should be using the PulseAudio output
> > > directly (although I know already that the version shipped with 1.1
> > > isn't all that good, nor is 1.2 version perfect; I'm working on it).
> >
> > I do get similar messages from the audio apps like mplayer, avidemux,
> > rezound etc. Repeatedly clicking on the play button (which triggers the
> > same message box every time the play/next/previous button is pressed) a
> > few times makes it work. Sometimes, relaunching the app is the only way
> > to get it working.
> >
> > As far as xine configuration is concerned, I've configured "auto" for
> > both audio and video and "default" for audio device. I've also tried
> > specifying alsa and pulseaudio plugin as the output but, to no avail. I
> > get the similar messages about the audio device not being available.
>
> My educated guess is that some of your apps use PA natively, others
> don't but hardcode are configured to use the raw ALSA devices, or raw
> OSS devices. Now, PA closes all devices after a short time of
> idle. So, what might happen to you is that you first use a native
> app. That causes PA top open the device. If you then use a non-native
> app, then it won't work.  But after the idleness timeout it will
> suddenly and magically start to work, because PA closed the devices.
>
> Lennart