In addition to the question I posted earlier about PREEMPT_RCU, I've
found still other kernel config options that are not covered in most of
the extant howtos for setting up low latency kernels, because they are
recently added in the unpatched kernel. (Or at least, they're more
recent than most of the howtos...)
I've been researching these options, mostly by googling (and
googling...and googling) the Linux Kernel Mailing List archives, and
also by looking at the config used by 64Studio, since it seems the
prevalent opinion is that they are stable as a rock. With the latter
approach of checking against 64Studio's config, I've had little luck
though, because their distro currently comes in a 2.1 "stable" version
that is based on Debian "etch", with a 2.6.21 kernel that predates the
existence of some of the config options I'm asking about; and a 3.0
"beta" version that uses a newer kernel, but should also probably be
taken with a grain of salt, because 64Studio is still working the bugs
out of it, and because it seems to have options turned on that the LKML
archives have warned strongly against. So, most of the information I've
gleaned has been from the LKML.
I might as well collate these questions here, for what good it may do.
The kernel I'm configuring is 2.6.29.6 with matching RT patches (-rt23),
though all of the options listed here are actually present even in the
unpatched 2.6.29.6 kernel.
PREEMPT_RCU :
This was the one my original question was about in the earlier post.
In the newer kernels (even mainline ones, without any RT patches), there
is a choice of "RCU Subsystem", with one option being "classic", and
other being "preemptable". The choice would seem obvious for low
latency, except that the help text warns that a preemptible RCU is
likely to expose serious kernel bugs that may render the system
completely unstable. (This is *not* the same setting as the various
CONFIG_PREEMPT options that have been present in the mainline kernel for
awhile now. This is something new, and it appears in menuconfig as a
separate setting.) I think I've mostly gathered from reading through
the whole process of debugging that the kernel gurus went through that
as of last year or so, this is now considered mostly stable, after
having been subjected to a utility called 'rcutorture', and having fixed
many lockups. I'd still be interested in anything anyone else can
contribute about it though, especially if they're using it and they
also think it is stable.
GROUP_SCHED :
This one is interesting, and I don't know what to make of it, other than
that the LKML seems to have decided in the last two months or so that it
slows your system down and makes latencies worse.
The thing that's confusing about it though is that it's
described as a mechanism for grouping high priority tasks by group.
It's implied (though not spelled out specifically) that they even mean
by this Posix groups, because in one document I read, it says that
enabling this will cause you to be unable to get realtime as a non-root
user unless you are setup in a group specified in limits.conf. Hmm!
That sounds an awful lot like what we've just been calling pam_limits
for years now. Are we doing this with a kernel config option now? (One
which apparently doesn't work?)
The 3.0 (beta) version of 64Studio turns this on. Then again,
looking at their kernel config, they seem to turn everything on, and
that might be why it's considered beta. (The 2.1 stable version of
64Studio seems to have a kernel old enough that it never had that
option as a choice.) Anyone have any feedback about this? It's only in
the past two months that the kernel gurus have decided that it's bad,
but they're actually considering marking it broken from what I've read.
CGROUPS :
This sounds cool, but I'm reasonably sure it's not actually necessary.
Documentation I've read suggests that this allows for letting
applications (or users) define CPU and memory pool affinity for tasks,
so that one could arbitrarily tie down particular threads or tasks to a
given processor core, or region of memory (or something like that).
However, the thing that makes me somewhat sure I don't positively need
this is that the same documentation also says that if you want to use
it, you need to create a new subdirectory under /dev, mount a new
pseudofilesystem under it, and then this module will populate that space
with dynamic configuration data about these affinity groups for running
tasks. I have neither seen any distro (even ones made for musicians)
that has set any such thing up out of the box, nor have I ever seen a
realtime howto that tells people to do it themselves. It sounds like
there's a lot of infrastructure necessary for this that's not common in
distros yet. (Though I see that regular Debian "lenny" turns this on in
the kernel without actually providing the special /dev support for it,
which I presume they're thinking you'll setup yourself if you're
interested.) Still, comments welcome...
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
Hello list,
I need to control the amplitude of one channel by the amplitude of
another channel, is there some LADSPA/DSSI plugin to do this or do I
need to write my own?
Cheers, Ralf Mattes
--
R. Mattes
Hochschule fuer Musik Freiburg
rm(a)inm.mh-freiburg.de
Awesome flood of new music from Linux land!
Is anyone/everyone adding these to lam.fugal.net? I'd like to start automating the downloading of all these tracks into my Sansa Fuze. Linux radio!
-ken
Are there any Linux apps like this which will take MIDI in via ALSA MIDI and/or JACK MIDI?
http://www.gootar.com/piano/
That would be sweet. Play a chord; get its name.
Alternately, if no such thing exists, is there any way to get ALSA MIDI into Javascript to use as input into this app?
-ken
2009/7/20 Pablo Gómez Poch <pblgomez(a)gmail.com>:
> 101 not fully supported; playback does not work correctly (periodic clicks)
>
> I use an Edirol FA-66, works ok over Firewire 192KHz/24bit
Hi Pablo,
I guess you use Freebob, isn't it?
Can you tell me if the FA-66 can work without jackd?
I'm really thinking to buy the FA-66 instead of the UA-101...
Thank you for answering!
This is for all those who might have tried seq24 with jack2.
Attached is a patch containing modifications made by
Stéphane Letz, the developer of jack2 who was so kind to
have a look into the seq24 code yesterday.
In the original setting, seq24 was not able to do a proper
client connection and failed working with jack2 transport. It also fixes the deprecated call to jack_client_new.
It applies to src/perform.cpp , hope it works as a patch...
Thanks very much Stéphane.
Cheers
Frank
Looking over Linux kernel list archives and other places, it looks like
when the "RCU Implementation" choice hit the mainline non-patched
kernel, the option to choose "Preemptable RCU" caused quite a stir as
many latent bugs were uncovered.
It looks like many bugs got fixed, but is it safe now? Should one
enable CONFIG_PREEMPT_RCU on a 2.6.29.6 kernel these days? It seems to
be available even without RT patches.
--
+ Brent A. Busby + "We've all heard that a million monkeys
+ UNIX Systems Admin + banging on a million typewriters will
+ University of Chicago + eventually reproduce the entire works of
+ Physical Sciences Div. + Shakespeare. Now, thanks to the Internet,
+ James Franck Institute + we know this is not true." -Robert Wilensky
hello,
i own an eeepc 4G (701) but ALSA makes a lot for underrun withe de Intel
soundcard (snd_hda_intel). Surprisingly, using the OSS emulation works
better. I don't think it is a question of CPU load (900Mhz) but rather a
problem of IRQ of the sound chip. Is it possible to tell to
snd_hda_intel to force the useof the soundecard in a better IRQ ?
Here is my /proc/interrputs for intel by defa
16: 56715 IO-APIC-fasteoi uhci_hcd:usb4, HDA Intel,
i915@pci:0000:00:02.0
my kernel is :
2.6.28-12-netbook-eeepc #43 SMP Mon Apr 27 16:06:05 MDT 2009 i686
thanks if you have any advice on putting something in modprobe.conf
to get more priority to sound.
- ben
Hello everyone!
I just uploaded a new piece. This time I have to give one aknowledgement
(besides the obvious programmers):
Thanks to Jeronimo Schoeber for his samples of the ocean. They are CC by SA,
alas not yet online, for his server is down. If someones interested, I'll drop
a line when these samples are up.
The title is "Dreams of music for a new world" it can be downloaded here;
http://juliencoder.de/dreams.ogg
Before I drone on a bit, I'll say enjoy to all, who leave me here and please
send some feedback, if you have something (either good or bad).
Software used - as always - was the usual bunch: Nama/Ecasound for
recording, LinuxSampler (for brass and drums) loads of ladspa plugins.
Special in this recording is the coconut I used as part of the beat.
Oh and here are some lyrics:
Dreams of music for a new world,
Of sand and seas
And wavy swirls
And harmonies...
Woven in(to) the new world.
And all discrepancies
Are firmly hurled
Into harmonies.
Mirrors floating on the off-beats,
Where gost notes swing
And the bass repeats
For nothing...
In the dream-light
Of drifting minds,
In moonlit night
And pantomimes.
Happy listening!
Friendly regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
Is it a known problem that any host supporting VSTs (via vestige or
otherwise) will not work with multi-threaded jack?
The very-generic message from wine:
jack_client_new: deprecated
no message buffer overruns
jack_client_new: deprecated
no message buffer overruns
The VST will start (Guitar Rig 3 in this case) but wineasio finds nothing
for input or output (no sound in or out as observed from the visual
indicators on the VST GUI).
