[LAD] tschack ... early version of smp enabled jack1

alex stone compose59 at gmail.com
Wed Jan 27 20:28:44 UTC 2010


2010/1/27 Stéphane Letz <letz at grame.fr>:
>
> Le 27 janv. 2010 à 21:02, Jörn Nettingsmeier a écrit :
>
>> On 01/27/2010 08:39 PM, alex stone wrote:
>>
>>> 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
>
> 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

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 at openoctave.org
development-subscribe at openoctave.org



More information about the Linux-audio-dev mailing list