On 9/29/05, Holly Bostick <[EMAIL PROTECTED]> wrote: <SNIP> > > > > 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?
I need X. I run Ardour as well as a number of other audio gui apps. http://www.ardour.org/ > > 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. Certainly. And this is not the first time I've been through this having now been using Linux audio for 4 years. Belive me, I've had many machines that didn't work for a while. This experience is not an exception - it's pretty much the rule. Clearly though, in my mind, this current problem is one of two things: 1) The recent kernel's are known to produce good results on 32-bit machines while running X. Unfortunately the current patch sets are not building for me as a 64-bit kernel. This could be because of configuration chices I'm making or somethign else. The kernel patch developers will eventually catch up to my issues and things will improve. 2) There is a specific hardware or driver problem with the NForce4 motherboard. Possibly the motherboard doesn't work well, or possibly the drivers have some problems. The former is not desired. The later will get attention eventually. > > 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. Good questions. I didn't say this earlier. I probably should have. If I boot this machine into a console mode (i.e. - no xdm/gdm) and run Jack in one console I can log in as root in another console, do emerges all day long and I get no xruns, at least with the small amount of testing I've done so far. This is using 2.6.14-rc2-mm1 so it has some new code but not all of Ingo's stuff. > > 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. Right, but as I say, much slower PCs are able to use the standard Gentoo kernel and run Gnome with no xruns. It's only this 3GHz 64-bit machine that has the problem. The sound card has been used in an Athlon XP 1600+ machine and it works fine so I trust its drivers at least in 32-bit mode. > > It's of course quite possible that I'm talking out of my butt, Not the least bit possible. Your thought are clear and very coorect IMO. > 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. Absolutely. Hopefully with the additional info above you'll see that is what I've been doing, within my limited abilities to patch kernels, etc. > > 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. Right. FVWM, fluxbox, etc. These can just be tested. > - 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. Neither are really acceptable as far as I know today. > > 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? As above - see Ardour, Jamin, Muse, Rosegarden, etc. Thanks for your thoughts. They are helpful. Cheers, Mark -- gentoo-user@gentoo.org mailing list
