Mark Knecht schreef: >> 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 > <snip> > > 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.
OK, so X really is a problem, then. Now I really want to find a way to get you rid of it. > > >> 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. Honestly, we don't care what much slower PCs can do, because this isn't one of them, and we don't think there's something wrong with the sound card. The issue is that this particular machine is a 64 bit one that apparently needs special handling in order to minimize the pre-existing latency issues with 64-bit kernels/drivers/environments so that you can use it for what you intend to use it for. Other conditions are irrelevant, imo. > >> 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. Patching the kernel isn't simplifying the environment if you're piling possibly unnecessary additional demands on the kernel. The X server runs on top of the kernel. The window manager runs on top of the X server, which runs on top of the kernel. The whole thing is rather like a head wound (the premise being that even non-serious head wounds tend to heavy bleeding, obscuring the nature and severity of the wound itself). The use of the X server, and anything but the lightest possible WM puts additional stress on the system, which may be the straw that breaks the camel's back in this case. > > >> 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. No, I really mean twm, ratpoison, ion and the like. FVWM can be configured to be absolutely minimal, but learning to do that is an unreasonable distraction. Fluxbox uses too much X (has to draw toolbars and tabs and decorative windows). Even openbox might, and I don't know enough about pekwm or kahakai to know if they would be appropriate. If you must use X (which I will accept for the moment) for the GUI applications, well, fine, but what I'm suggesting is a window manager that uses the absolute minimum of X resources possible. > > >> - 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. I'm not completely convinced that Ardour, Jamin, Muse and Rosegarden won't run under DirectFB, but I'm not so experienced with DirectFB that I can say definitively one way or the other. I see that at least Muse does have an ncurses interface (or at least an ncurses USE flag which would suggest that it has an ncurses interface). And looking at the DirectFB site, it seems possible that there could be a place for it to help work around the issue: FusionSound Audio sub system for multiple applications FusionSound is a very powerful audio sub system in the manner of DirectFB and a technical demonstration of Fusion. FusionSound supports multiple applications using Fusion IPC. It provides streams, static sound buffers and control over any number of concurrent playbacks. Sample data is always stored in shared memory, starting a playback simply adds an entry to the playlist of the mixer thread in the master application. FusionSound currently is a module of DirectFB. The current API is fully implemented and the complete code is smaller than just the header file of DirectFB! There's a complete API Reference to learn more about FusionSound. FusionSound future plans include interfaces for hardware/software codecs, hardware gain control, device configuration and different device backends (currently OSS only). XDirectFB Rootless X Server based on DirectFB XDirectFB Screenshot XDirectFB is a rootless X Server using DirectFB windows for X11 toplevel windows. This way you can adjust the opacity of every application with your mouse wheel (while holding Meta down over a window). More details about these shortcuts can be found in the DirectFB README. Window movements are initiated by the applications or the window manager. The graphical movement is done by DirectFB using available hardware acceleration. Overlapping toplevel windows do not cause expose events, i.e. redrawing of the window contents, as they are DirectFB windows and therefore have an own surface, a.k.a. backing store. You should use the CVS version, because the last release is too old. Qt on DirectFB qt-directfb is a GPLed DirectFB port of Qt based on Qt-X11 3.2. Qingy (I've used this, it's nice enough. I mean, it's just a DM, after all, so not much to say) Qingy is a replacement of getty. Written in C, it uses DirectFB to provide a fast, nice GUI without the overhead of the X Windows System. It allows the user to log in and start the session of his choice (text console, gnome, kde, wmaker, ...). wyoDesktop wyoDesktop is an effort to create a graphical desktop environment where an ordinary user immediately feels comfortable through the use of a well designed and consistent look and feel. I know I'm very hardheaded (I have even been so evaluated by professionals in vocational assessment testing, so it's really true), but the upside is that I tend to believe that there is a solution or workaround to most problems, and I tend to go a long way towards twisting myself into a pretzel to find it (and the upside of that is that if I tie myself into a pretzel and find nothing, then there's really likely nothing to find). I understand that serious audio recording has serious problems under Linux, but I also know that many people are very interested in finding solutions. I just wonder if many of those solutions may not lie 'outside the box' at this time. It's within the realm of possibility that this could all work effectively (if not elegantly), if radical changes were made to the PC's setup, with the sole purpose of getting it working. Oh and by the way-- I noticed that both directfb and ardour (I think it was) seem to prefer Matrox cards. I've got two in the house (though only one is mine), neither in use-- a G400 and a G400Max (but the fan on the Max keeps falling off :) as I'm missing a screw I think, otherwise it's fine). Wanna discuss a trade for any old nVidia card you might have laying around? Seriously. Holly -- gentoo-user@gentoo.org mailing list
