Hi Mutil, On Wed, 25 Nov 2009, mutil wrote: I've found that zombies are actually very hard to debug. They happen when your application takes "too long" in the process() cycle (for whatever reason). It could be that you did a realtime violation (like allocating memory), or it could be that you used an O(N^10) algorithm. When you start jackd, it says something like: configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 4 periods The 21.3 ms is the time for /EVERYONE/ to get their audio processing done. If someone takes to long, jackd puts them to death. But, getting a 'jack zombie' is kind of like a hit-and-run. By the time you get declared a zombie, the 'thing' that caused it has sped off down the road anonymously. I think I've even seen it where the wrong application gets marked as a zombie. By the time jackd marks your program as a zombie, your O(N^10) algorithm might be done... and it looks like `int j=5;` caused the problem. :-) In the end, the best way I found to fix this problem is to statically audit your code for "real time violations." If your program is large, Doxygen has a feature to create static call graphs... which I found helpful. The JACK Documentation for jack_set_process_callback() says: The code in the supplied function must be suitable for real-time execution. That means that it cannot call functions that might block for a long time. This includes malloc, free, printf, pthread_mutex_lock, sleep, wait, poll, select, pthread_join, pthread_cond_wait, etc, etc. Notice that locking a mutex is in the list. However, it /is/ possible to use a mutex and be realtime safe... but this means that anything between lock and unlock must /also/ be realtime safe. In other words, anything done while the mutex is locked is essentially happening in the process() function that you've set as a callback. Consider this: QMutex mutex; float* buf; foo() { mutex.lock(); buf = new float[4096]; mutex.unlock(); } int process(jack_nframes_t nframes) { mutex.lock(); for(int j=0 ; j<4096 ; ++j) { buf[j] = 0.0; } mutex.unlock(); return 0; } process() starts by locking a mutex. If foo() already has it locked, that means that process() is going to have to WAIT until foo() unlocks it. But foo() is allocating memory dynamically (which you can't do in realtime sections of code). That's essentially the same as this: float* buf; int process(jack_nframes_t nframes) { buf = new float[4096]; for(int j=0 ; j<4096 ; ++j ) { buf[j] = 0.0; } return 0; } So you see, by using a mutex... you have to consider those sections of code as being a part of your process() function. Is the custom global buffer allocating memory while the mutex is locked? If so, that's your problem. A ringbuffer is a good way to do this. I don't know of any examples using the JACK API (maybe someone else does), but google for "producer consumer" and you'll get some good info on the subject. A note about using Qt in JACK applications: QString is not good to use in realtime sections. It does a lot of dynamic memory allocation behind the scenes. I know for sure that its constructors and its assignment operators allocate memory dynamically -- which means you can't create a new QString or even copy one while you're in a realtime section of code. Hope this helps, Gabriel

On Wed, Nov 25, 2009 at 12:17:39PM +0200, mutil wrote: The first question to ask is if you really need the buffer and mutexes. Normally in a Jack client you'd do the audio processing in the process() callback, and there's no need to buffer signals unless you want to do something with them that can't be done and finished immediately. Examples are reading/writing from/to files, or displaying the waveform or spectrum. For those you need to transfer the signals to/from non-realtime threads. Just mixing two inputs to one output would not require this. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.