On Thu, 2004-06-03 at 13:03, Free Ekanayaka wrote: > >>>>> On 02 Jun 2004 21:03:50 -0700, Fernando Pablo Lopez-Lezcano <[EMAIL > >>>>> PROTECTED]> said: > > Fernando> On Tue, 2004-05-25 at 17:41, Fernando Pablo > Fernando> Lopez-Lezcano wrote: > >> > seems that some people have done some deeper tests ( Fernando > >> Pablo > Lopez-Lezcano for ex.) which havr shown than the 2.6.x > >> kernel is not > good enugh yet for audio production. Maybe it > >> worth to take this into > consideration. > >> > >> And then maybe not :-) > >> > >> Another data point, I just (finally) booted into FC2 (that > >> comes native with 2.6.x/ALSA) using 2.4.26-1.ll+ALSA (as built > >> on FC1). I still get xruns. Much less than with 2.6.x but they > >> are there nevertheless. So there is something other than 2.6.x > >> messing things up (I suspect the xorg X server, but have no > >> hard data to back the claim). > > Fernando> So now I know (sort of) what was going on. The culprit > Fernando> was not the kernel. The culprit was not xorg. > > Fernando> The culprit was a change in behavior of pthread_create > Fernando> (what it is related to I don't know yet, I assume this > Fernando> change is part of glibc - I just found out a few minutes > Fernando> ago). That change means that the current jack code, > Fernando> together with glibc or whatever it is that changed in > Fernando> FC2, creates threads for the jack clients that are _not_ > Fernando> SCHED_FIFO (but jack itself is still SCHED_FIFO). You > Fernando> can imagine that that can cause xruns :-) > > Fernando> I just did a test with a hacked jack and things are back > Fernando> to normal (meaning that it should be now possible to > Fernando> really test 2.6.6 in my environment for low latency > Fernando> behavior). > > Fernando, thanks for this deep analysis of the issue. > > I'd like to know whether this bug holds even for Debian > glibc/2.6.x.
Apparently so, Jack O'Quin mentioned that the hack seemed to make some problems he had been seeing in jack under Debian/2.6 dissapear. BTW, I should have been more specific, this happens only with NPTL threading (not the normal pthread library). More testing is needed, I could reach a state where jack would pretty much hang the machine... killing jack returned things to normal (the machine was not hung, just very very very slow). > If this is the case I think that A/DeMuDi should really > stick to 2.4.x until the jack code is fixed upstream. -- Fernando
