Re: [gentoo-user] [Completely and totally OT] FVWM-Crystal...!!!

[Holly Bostick]

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@g.o mailing list