Fons Adriaensen wrote: > ISTR (but it's years ago - since the LAC where Zyn was > first presented) that Zyn uses FFT based processing for > some of its algorithms. If this is the case and the FFT > size has to be some minimal value then there's a problem > if the jack period is shorter. I don't know if such a problem is the case with zyn, but when I specify the -b 128 everything is just fine. To me it simply seems like a user-unfriendly design, where you must specify the buffer size on the command line, when theres actually one on possibility, namely the buffer size of the running jack server. I imagine this stems from zyn starting as a non-jack application, probably even OSS only, where it makes sense to specify the buffer size on the command line. Then I imagine that later when jack support was hacked into the thing, the code wasn't really structured in a way to make it easy to detect buffersize of a running jack server. This would fit with what cal wrote: "I've certainly thought about how to relocate zyn's application of those parameters until after initialising the audio, but I haven't tackled that monster yet". -- Atte http://atte.dk http://modlys.dk http://virb.com/atte _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
