On Sun, Oct 11, 2009 at 08:18:37PM +0200, Hartmut Noack wrote: > To stress this a little: LMMS runs very good under Linux if ALSA is in > charge directly. At least it feels much more stable, is quicker to > respond and does not introduce any crackles or noise. > > Thats why I have the impression, that tobydox could be tempted to think: > "Well then... let jack be jack - my app runs OK under Linux and I > designed it to be a one-stop kind of thing." LMMS SVN has a very well > implemented internal version of ZynaddsubFX. I would say, this points > in this direction also. > Its quite similar to audacity, that runs OK for many years using OSS and > ALSA and is quite behind in supporting jack seamlessly. In the end it should just depend on the amount of buffering, and consequently, latency, that an app needs in order to work in a stable way. In other words, if things are set up correctly it shouldn't matter if you use ALSA or JACK. But note that Jack does not provide any buffering by itself, it expects the app to do its work 'just in time'. I suspect that LMMS needs more buffering than provided by 'typical' jack period settings wich could be anyhting between say 64 and 1024 samples. Now if LMMS does have its own buffer between the processing code and the Jack interface then things should just work fine *IF* that buffer is used correctly - this would mean that not only it has to have at least the size needed to let LMMS work at ease, but that also it needs to be pre-filled (with silence) up to that size before starting. If this is not done, the buffer is in effect useless. It could be that it's just that what's missing. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
