Mark Knecht schreef: > On 9/29/05, Holly Bostick <[EMAIL PROTECTED]> wrote: > >> Mark Knecht schreef: >> >>> On 9/28/05, Mark Knecht <[EMAIL PROTECTED]> wrote: >>> >>> >>>> Great. Tried it. It worked fine and didn't upset Jack which >>>> means my experiment goes on. >>>> >>>> This is working so much better for me than Gnome on my AMD64 >>>> box. I'll have to go back and try the standard Gentoo kernel >>>> instead of ck-sources. >>>> >>>> <snip> >>>> >>> In the end the xruns came back so FVWM-Crystal didn't magically >>> solve my problems. (unfortunately...) >>> >>> My quest goes on. Now running 2.6.14-rc2-mm1, looking for >>> 2.6.14-rc2-mm1-rt6 >>> >> >> Am I the only one who doesn't know what are 'xruns'? Whatever they >> are, it would seem that the problem can be minimized, but not >> eliminated by choice of WM, but obviously we couldn't go any >> further in actually eliminating them without knowing what they are >> (or at least I couldn't, since I don't actually know what you're >> referring to). >> >> Holly > > > Holly, I'm so very sorry. Of course you would have no reason to know > about xruns if you are not part of the Linux audio community. My > apologies. > > One of the Linux 'methods', if you will, for moving audio between > sound cards and applications is a server called Jack (jackd) which is > supplied by emerging jack-audio-connection-kit. Jack provides for > the movement of digital audio between a sound card and essentially an > unlimited number of apps (really 'ports') with a known latency. It's > the latency that's really important to those of us doing live > recording. If I'm listening to a piano and recording my guitar then I > need the two to sound like they are in time or it is virtually > impossible to play a part correctly. > > An 'xrun', standing I think for overrun - go figure - is when > something in the system has not taken or delivered digital audio at > the agreed upon time. This leads to clicks and pops. If you were to > look at the waveform in an oscilloscope there would be some sort of > discontinuity. > > With my 32-bit machines I have been blessed. I have been able, for at > least the last year, to run the standard Gentoo kernel at <3mS > latency with no xruns. I've been writing and recording music on > Gentoo and had no problems while others running on other distros have > had to build specialized kernels utilizing patches from Andrew Morton > and Ingo Molnar to get equivalent results. On guy in Australia didn't > really beleive me so I helped him build a Gentoo box over the net. > When that machien came up it worked so well, with the standard > kernel, that he converted all the machines in his studio to Gentoo > and no brags about how stable his environment is. > > I looked forward to such an experience with my new AMD64 machine. It > did not come to be true. > > Every 64-bit kernel I've tried so far either has terrible xrun > problems or will not build. This includes: > > gentoo-sources - xruns ck-sources - xruns kernel.org - 2.6.13.3 & > 2.6.14-rc2 - xruns 2.6.14-rc2-rt6 - Ingo's patches - won't build > > I'm currently running 2.6.14-rc2-mm1 - with Andrew Morton's patches. > I have not yet tested it but at least it built. > > The major change to the kernel to get better real time results is > (apparently) to make pretty much everything preemptable. When Ingo's > patches are added then a new preemption model shows up in make > menuconfig. Unfortunately for me it won't build on 64-bit yet, at > least for me. > > The window manager choice is just one choice those of us playing with > low latency audio make. KDE has never worked well for me. Gnome has > been fine for the last year until this new AMD64 experience. In the > old days we used fluxbox over KDE and Gnome and got good, but not > great, results. > > Anyway, I hope that helps explain my xrun comments. >
OK, sorry not to snip, but your post is a continuous thought/explanation, and it doesn't seem right-- and I don't top-post (99% of the time). I have several questions mostly leading to the same ultimate end. But only one is important to express: 1) do you actually need X? i.e., is it possible to record audio in the manner that you do without it? What occurs to me, looking in from outside, is that while your issues are clearly known to be kernel-based, and 64-bit based, the fact that you are using programs that interfere with latency/real-time issues is obfuscating the entire problem. Certainly if the choice of window managers has an effect on the severity of the problem. So clear the waters if you can, because you can't solve a problem that you can't clearly see the outlines of. Can you record audio from the command line? Or do the X-based programs you use run under DirectFB? What I'm getting at is getting rid of all the obstructions that could possibly interfere with the kernel and introduce even more latency issues than what it already has, so that you (or any devs) can see what problems it already has distinctly enough to solve them-- or to eliminate them sufficiently so that you can get on with doing what you do until the kernel stabilizes so you can use it normally. I mean, X is a horrible hog, heaven only knows what effect your nVidia or ATI kernel modules may be having on the ability of the kernel to behave properly, since they also make demands on the kernel that 'distract' it, as it were. And if Jack is a daemon (which I know it is), it's not like it needs X for itself. It's of course quite possible that I'm talking out of my butt, since I am not a member of the Linux audio community, but I do know that the first step in troubleshooting is to simplify the environment as much as possible, and then slowly increase the complexity to see when and where things break down. Were I you, I would consider: - If keeping X, switching to the absolute most minimal wm possible (twm, ratpoison, ion), to see what effect that had. - If downstepping from X, investigating what programs run under DirectFB and seeing what effect that had. - If going cold-turkey off X, seeing how far you get with the command-line and ncurses programs. Am I, in fact, talking out of my butt (since it seems that the 'real' audio community would have tried at least some of this)? Or are there reasons that this simplification process is not possible for professional audio recording? Holly -- gentoo-user@gentoo.org mailing list
