27 Jan
2010
27 Jan
'10
4:28 p.m.
2010/1/27 Stéphane Letz <letz(a)grame.fr>fr>:
Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :
Stephane, you make a fair point, but i will say again here, tschack is
an experimental version of Jack1, and as Torben has already indicated,
it's not going to be mainstream.
On the brighter side for all the community, there's an opportunity
here, with the above in mind, to experiment with other features and
components that might prove useful for consideration in both the
malnstream versions in the future.
I for one, and i only speak for myself, think it's of potential
benefit to the community to try new features in a non public, more
controlled environment, and aid Torben in this experiment however i
can.
I shall continue to do so.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
On 01/27/2010 08:39 PM, alex stone wrote:
Well "jack2's apparent overhead," is something new for me, and would
require some deeper test/feedback to understand better. Moreover without more precise
description of xruns occurrence (at what DSP CPU does it start to happen.. etc..) , what
kind of setup (jack2 version, jack configuration, applications used....), it is again hard
to understand/correct things.
Stéphane
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
It's been a good day, and i've enjoyed
the stability. I used jack1
before, because it gave me fewer challenges, xruns and occasional pops
and spits, than jack2, which i ended up having to ease out to
48000/512/3, to reach near the same performance. (i'm on 48000/256/3
with jack1)
for some more anecdotal evidence, this is about what i was seeing during
my jack1/2 comparison tests. jack2 generally required one buffer size
step more to achieve the same xrun robustness as jack1. but i'm
generally able to use much lower latencies down to 64 (or 128 in the
jack2 case), unless i use jconvolver, which forces me to go to at least
1024 so as not to max out the cpu.
i didn't think too much about jack2's apparent overhead, since it has
the benefit of scaling to smp, which usually affects the
single-processor case (my box is a single-core amd64).
it would be interesting to see if torben's approach is able to deliver
the same latencies as jack1, while adding smp support.
regards,
jörn