2 Jul
2004
2 Jul
'04
10:39 a.m.
At Fri, 2 Jul 2004 13:26:44 +0200,
Florian Schmidt wrote:
On Fri, 02 Jul 2004 11:40:28 +0200
Takashi Iwai <tiwai(a)suse.de> wrote:
Yes, but i wonder: many other people use NPTL for many kinds of
applications w/o problems.. The jack source code is too complex for me
to really find my way through it, but maybe someone might consider
summing up how jack handles threads and provide pointers into the
source at the relevant spots.. Maybe NPTL isn't at fault, but jack..
Well, it's hard to determine at this point.
It could be a bug of pthread_setschedparm() on NPTL.
When the
dust settles from the kernel and NPTL, 2.6 will be more
viable. Right now, even though it works for some people, its not a
generally viable platform for realtime audio.
Hmm, except for some sched policy setting problems on NPTL, I don't
see bigger problem than 2.4+preempt kernel. For some people,
2.4+preempt might work _casually_ better than 2.6, but it can happen
vice versa.
Shouting "DON'T USE 2.6" isn't a good solution. Though, we need to
inform to "set LD_ASSUME_KERNEL as a workaround"... Also, i think it would be very useful to have
simplified test case
which shows the "erraneous" behaviour of jack/NPTL..
Yes, definitely.
Takashi