On Thu, 17 Sep 2009, Grammostola Rosea wrote:
>> You seem to be somewhat alone with this one. No offence, but it does
>> sort of hint that your system setup might be less than ideal. With a
>> little more info, some help/assistance might be possible.
> I think my system is configured pretty well. I have no problems with any
> other audio app.
When I was tracing 'zombification' issues in Hydrogen, it was very helpful
to me (the developer) to know:
* jackd settings when firing up the application
(e.g. jackd -R -d alsa -p 4 -n 2 -r 192000 -Xseq)
* A little more about the system (memory, CPU,
distro, jackd version)
* Any command-line options you used to start
the application and cause the fault.
Obviously, Zombies happen more often with aggressive JACK settings.
On the other hand, even with that info it is generally hard to trace out a
Zombification issue. The zombie notification happens a few milliseconds
_after_ the event that waited -- so, backtraces weren't very helpful.
Increasing your logging can corrupt your measurements because I/O is one
source of a zombie. It was even possible, for instance, for one
application to take just a little too long (leaving no time for the 2nd
app). JACK would then blame the zombification on the 2nd app.
I ended up having to do a static code analysis to search for memory
allocation, re-do our logging scheme (because its mutex was causing
locks), and discover some new taboo functions. The biggest surprise (for
me) is that Qt's QString constructor and operator= could not be used in
real-time code.
HTH,
Gabriel
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
