On Wed, Apr 02, 2014 at 10:31:42PM +0100, Will Godfrey wrote: > I, and a number of other people, have found that yoshi is consistently more > stable, reliable and less prone to xruns under stress. > > ... > > I frequently use very large patch sets. zyn is unable to load these even > if it saved them. I'm informed that this has been dealt with in one of the > development branches, but when that will appear in the release version is > unknown. For me, this is a show-stopper.
In regards to this issue, I'm going to have to firmly sit with the approach that I've been implementing in ZynAddSubFX for quite some time. First, the overall issue is that both codebases have a lot of real time Faux pas. The difference is how the projects have gone about trying to fix things. In every case that I have observed in yoshimi where an xrun is less likely to occur it is due to undefined behavior (almost exclusively through threading). For the longest time the user interface has synchronized everything with a horrid mutex, which was used in such a way that it really broke realtime guarantees in quite a few dimensions, but when it was used it did ensure that well defined program behavior was present. I have seen a number of locations where yoshimi has simply omitted the use of this with nothing else to stop nasal daemons from popping up. This approach certainly can be seen as a shortcut to a better experience, but it's not really a true fix. I'm not encouraging the use of non-realtime operations at all, but in the mean time I'll take a well defined error over undefined behavior. As for a real fix, in what I've been calling the anti-broken system I've made sure that this mutex is quite solidly dead and unsafe/costly operations do not interfere with any audio generation. This branch was quite time consuming to implement and the internals are working quite well for the most part (and this conversion has also resulted in a number of features that are getting fine tuned such as arbitrary midi learning, OSC exposure of *all* parameters, basic undo, etc). As per when this will appear in a release version, that will happen as soon as I stop finding regressions in the user interface. I cannot nail down any set timeline as I'm the only person actively working on this part of the code and coding time varies wildly. So, I'm fine with yoshimi continuing to plug along, but there seems to be some FUD surrounding it's relationship to ZynAddSubFX. This FUD goes back to some of the origins of the project when the code changes were purported to drastically improve performance when 95% of that claim was simply a basic change in compiler flags and those flags along with the 5% (and then some) have all been integrated for those curious. Does it appear to do some operations better than the current released version of ZynAddSubFX? Yes, loading a very large patch in the master version does end up blocking. (In the ABS version this is simply a pointer swap) Does it do so in a manner that is well defined and maintainable? Not in my opinion --Mark McCurry
pgpniokTB8dEp.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev