[LAU] [Zynaddsubfx-user] zyn and the art of software maintenance

rosea grammostola rosea.grammostola at gmail.com
Thu Sep 17 08:02:02 EDT 2009


rosea grammostola wrote:
> Gabriel M. Beddingfield wrote:
>>
>>
>> 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.
>
> /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p128 -n2 -Xseq -zt
>
>
> jackd (0.116.2+svn3592-3)
>
>
> Debian testing, Pentium 4 32bit
>
>
> The only strange thing on my system
>
>
> This is in my /etc/security/limits.conf
>
> @audio - rtprio 99
> @audio - nice -10
> @audio - memlock 970215
>
>
> But ulimit -l
> give unlimited
>
>
> I tried to figure out how come on #jack, but no solution yet
>
> But afaik Zyn should also run properly with unlimited...
>
>
> \r
>
>
>
>
The 'normal' zyn in debian testing 2.4 works a lot better all though it 
zombifies too sometimes after a while. (that's why I always use the one 
from git, but that's offline now at the moment)



\r




More information about the Linux-audio-user mailing list