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

[Kevin Williams]

On November 20, 2007 03:14:47 pm Lennart Poettering wrote:
> The suspend timeout is controlled via the "timeout" parameter of
> module-suspend-on-idle.

I commented that line out now and it still doesn't help in anyway !

Running xine with verbose mode gives me the following messages:
####################################################
*** PULSEAUDIO: Unable to connect: Invalid argument
*** PULSEAUDIO: Unable to connect: Invalid argument
AFD changed from -2 to -1

---------------------- (ERROR) ----------------------
The audio device is unavailable. Please verify if another program already uses 
it.

['Audio device unavailable' '']
------------------ (END OF ERROR) -------------------


---------------------- (ERROR) ----------------------
The audio device is unavailable. Please verify if another program already uses 
it.

['Audio device unavailable' '']
------------------ (END OF ERROR) -------------------

*** PULSEAUDIO: Unable to connect: Invalid argument
AFD changed from -2 to -1
################SNIP##########################


My guess is that, pulseaudio is not fast enough to respond to the clients 
requests as hitting next/previous with a brief pause say 6-7 seconds does not 
produce any error message nor does make it the app crash. Hitting 
next/previous in quick succession gurantees the error messages followed by a 
craash. Hitting next/previous with a gap less than 6 seconds produces the 
error message most of the time. But, anything less than 3 secs would 
definitely produce those errors.

As I've mentioned before, all the apps work fine when using alsa or arts 
without pulseaudio. Hitting next/previous in rapid succession doesn't cause 
any problems and it works.

Any pointers ? Should you need more info I'd be glad to provide.

Thanks.

Kevin


> On Tue, 20.11.07 14:14, Kevin Williams (kevkim55 at gmail.com) wrote:
> > 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 !
>
> exit-idle-time is unrelated to this.
>
> The suspend timeout is controlled via the "timeout" parameter of
> module-suspend-on-idle.
>
> > 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 ?
>
> No, unfortunately not. It would be helpful if you could get your hands
> on some more verbose Xine debug output, though.
>
> Lennart