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
