11 Oct
2009
11 Oct
'09
8:35 p.m.
On 10/12/2009 08:40 AM, Fons Adriaensen wrote:
On Sun, Oct 11, 2009 at 03:16:50PM -0500, Jonathan E.
Brickman wrote:
In other words if someone from the lmms team wanted to get some
assistance with the jack code that is not working they should feel free
to send it to the jack-devel or LAD list for assistance. However
relying/hoping or expecting someone unrelated to the project to go out
of their way to figure out the issue on their behalf is unlikely to get
anything done.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
I do understand how quality Jack interfacing
could be a surpassingly
difficult challenge for a developer, most especially a group of
developers, of an insular yet modular project like lmms. I could
imagine that it might require reworking of the audio output code for
each module, given that the whole was never designed for jack in the
first place; and there are a lot of modules. Culturally speaking,
within many FOSS developer groups, such changes are very difficult to
enact short of a fork. I have also heard tell that qt4 is unhelpful in
general latency-wise, but this does not explain why ALSA output works well.
I suspect you missed the point.
If LMMS works well, and with acceptable latency (whatever
that means) using ALSA then it should work equally well
and with exactly the same latency using Jack.
* There is no essential difference except in the
* way this this achieved.
The difference in practice is that an app can set up its
ALSA interface to provide lots of buffering (with the
associated latency), but it can't do the same with Jack.
Using Jack it has to provide the buffering itself. Since
LMMS, according to previous posts, has buffering between
its DSP modules and the Jack interface the only thing that
could be missing is to set up this buffering as it should
be set up. If this is done there is no need to modify any
modules.