[LAD] some questions about writing a jack client

[Arnold Krille]

Hi,

On Wednesday 25 November 2009 11:17:39 mutil wrote:
> 	I am trying to write a c++/qt4 jack client which mix 2 inputs and has a
>  jack output. The problem is that currently jack gets zombified too often
>  and I would like some info on how can I debug the exact reason this
>  happens. I suspect it's the way the app is written and I am planning to
>  rewrite it but I need some advices first.
> 	The way it's currently written makes use of mutexes and locks to pass the
> data beetween a custom global buffer. Is this the reason for not
>  synchronizing good enough and zombifies jack or it's something else that
>  screw things?

Locks and waits are not realtime save. So don't ever use them in a realtime 
thread. When the realtime thread is waiting on the gui-thread to release a 
lock, why separate the threads at first and give one higher priority?

>  Should I use a ringbuffer (which, to my understanding is
>  lock-free and doesn't need mutexes) to get the work done, and if so, are
>  there any jack2 example of this or some hints for what I should be aware
>  of?

Ringbuffers are only lock-free when one thread is always _only_ reading and the 
other is always _only_ writing. But for an (usable!) example of a lock-free 
ringbuffer, see ringbuffer.h shipped with jack. Guess what its intended usage is 
;-)

>  Or have I misunderstand something completely?
> 	Please, any recommendation of how I can eliminate this "jack zombified"
>  thing and understand the whole realtime issue is welcome.

Basically multiple threads should not wait on each other. If they have to 
wait, they are depending deep enough to become one. If one thread is supposed 
to work realtime, don't ever make it wait, that is don't use locks, don't 
acquire or release memory with malloc/free/new/delete...

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091125/b1f03751/attachment.pgp>