Hi! I recompiled my mplayer against the new jack, but it still continues. Mplaer gets zombified quite often. And as I said, this problem occured with the previous jack as well. But it jst set in recently. Up to a week ago I didn't have any trouble with it. And I can't really say what I changed. The only thing is, that about two weeks ago I installed my new kernel 2.6.21-mm2, before I had 2.6.16.2. But why should over a week pass before this makes problems? Any more ideas where I can look, what I can try? Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Hi Dragan! I'm on debian stable. And I didn't install anything lately. I only made my own kernel, and my own mplayer and yesterday my own new jack. Those packages I always build myself. I think I'll have to give it another try with the old kernel. Kindest regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

Thanks Dragan! I'll try setting the timer-rate lower. Best Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Wed, Jul 11, 2007 at 03:18:42PM +0200, Dragan Noveski wrote: [snip] [snip] Thanks for the tip, I'll have to recompile my kernel again. But still I don't think this is the cause for Julien's problem. I was having very similar symptoms after installing the latest jack from svn last week. At the same time a new version of gstreamer0.10-plugins-bad got into Debian testing, with the new jackaudiosink. The gstreamer update came a bit bad time, because now I don't know if the frequent zombification, time-outing and watchdog barking is due to some new jack bug or the gstreamer applications constantly entering and leaving the processing graph, triggering some old misfeature (it seems that the time-outs can happen at random times, but I'm not sure, because mostly they happen on graph changes and on my system the graph can change unexpectedly due to a cron job). Anyway, my solution was to add a --timeout parameter (with value 4000), and now jackd has been running happily for a day without the watchdog coming and killing everyone in sight. Pulseaudio and Ingen has been mysteriously zombified only once, as opposed to every 15 minutes, and everything else has been working fine, although there haven't been much stress on the system during the last day. A related question: what does this error message exactly mean? subgraph starting at <client> timed out (subgraph_wait_fd=<number>, status = 0, state = Running) Every client is only connected directly to the sound card playback ports, so the subgraph shouldn't be particularly long. Does the error mean that the said client didn't return from its processing function fast enough or what? After that message jack used to stop delivering audio and then after a few seconds the watchdog would come and eat everyone. I still have got that error twice (the Pulseaudio and Ingen zombifications), but the whole jackd hasn't died anymore. -- Tanu Kaskinen

On Wed, Jul 11, 2007 at 01:33:49PM +0200, Dragan Noveski wrote: You may have caught the middle of the ffmpeg transition. afaik, ffmpeg never do releases so debian has to take a snapshot of their current svn, or whatever revision control system they use. Then they have to get all the ffmpeg using apps rebuilt against that one snapshot, which can sometimes be tricky because ffmpeg interfaces occasionally change. -Eric Rz.