#30 Thread zombification with jack

v2.5.0
closed-fixed
None
5
2015-02-14
2010-11-17
No

When more than a minimal load is place upon the synth (more than 2-10% of a single cpu depending on nice settings) the synthesis stops and jack disconnects zynaddsubfx.

The ui remains responsive however the only way to get sound back is to restart the program.

Upping the nice value mitigates it a little however only delays the problem. At best I could use 11% of a single cpu (on a modern quad core system) before running into the problem.

I have a feeling (correct if wrong) that this could be a threading granularity problem. Does zynaddsubfx use real-time threads on linux for it's main audio thread? Does the zynaddsubfx architecture lend itself to it?

While I have made small patches to other synths before I am not familiar with zyn's code base, any pointers as to where to start trying to resolve?

Discussion

  • James John Walsh

    Got the latest git using Nio compiled, and it's even worse there, the moment any of the default instruments that come with it are loaded the jack thread is zombified without even any midi key being pressed.

    ZynAddSubFX - Copyright (c) 2002-2009 Nasca Octavian Paul and others
    Compiled: Nov 18 2010 01:52:09
    This program is free software (GNU GPL v.2 or later) and
    it comes with ABSOLUTELY NO WARRANTY.

    Try 'zynaddsubfx --help' for command-line options.

    Sample Rate = 44100
    Sound Buffer Size = 1024 samples
    Internal latency = 23.2 ms
    ADsynth Oscil.Size = 1024 samples
    Starting Audio: JACK
    Audio Started
    Starting MIDI: JACK
    MIDI Started

    Thanks for using the Nio system :)
    Jack reports error: jack_client_thread zombified - exiting from JACK

     
  • Mark McCurry

    Mark McCurry - 2010-11-18

    This has been a big issue with zyn.
    Almost any action with the actual backend from the UI or midi resulted in a global lock "master->mutex" [see src/Misc/Master.h].
    This makes any real time generation choke.
    There are also a number of real time unsafe things that zyn does a fair bit in its codebase like dynamic memory allocation and I will state that this is a royal pain to attempt to resolve.

    Nio was created partly in an attempt to help to resolve some of this problem, but as you can see it is not terribly effective.

    As per the zombies, I dare say that jack has a --nozombies or similar option.
    This will result in a cracke happening rather than a crash, which is better, but not a real fix.
    If you know a good non-locking method of swaping out large bits of synth data, then this could be something interesting.
    Some other work was done in git:experimental with the idea of message passing to help decouple the backend from the UI to get rid of locks.
    (finer grained locks were attempted, but this made everything much worse)

    Also if you look at the mailing list archives, there was a fork over this issue, with a Cal.
    At this point no code is being actively communicated between groups due to some hostility between parties.

    The key is that master->mutex and its aliases are the main challenge.
    Without them, threads are unsafe, so at the moment one poison or the other.
    I assigned this issue to myself, so I should be reminded to reply to this issue if you have any concerns/ideas/etc.

     
  • Mark McCurry

    Mark McCurry - 2010-11-18
    • assigned_to: nobody --> fundamental
     
  • James John Walsh

    I'm presently having a look at software transactional memory, I have not yet seen anything that looks like a show stopper but I must admit I have never dealt with lockless threading before.

    Even if it adds a few more percent overhead if it stops the crackling and thread death I'll be satisfied. If it winds up being a suitable route there are libraries such as TBoost.STM and the like that could be of use.

     
  • Mark McCurry

    Mark McCurry - 2015-02-14
    • status: open --> closed-fixed
    • Group: --> v2.5.0
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks