| [proaudio] Fw: Re: Subscription probs & rt-sources |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/proaudio Archives
]
Daniel Santos wrote:
Hello, either my email server is screwing up again or my attempt to
subscribe to proaudio-request@xxxxxxxxxxxxxxxxxxx didn't work, so
please reply-all or CC me on responses (and evermind, please subscribe
me if you can).
I've subscribed you. So welcome to our list finally;)
I'm expecting to acquire a digiface by the end of next week, so I'm
trying to get this stuff up and running. There are some HOWTOs that
are in need of update (Gentoo/Jack HOWTO, etc.) and I figure that's
something I can do after I'm done "learning the lessons" that need to
go into it.
A. We should maybe remove the rt-sources-2.6.25.8-r7 ebuild. It would
appear that Ingo Molnar (the rt kernel maintainer) has moved all of
the 2.6.25.x rt patches to the "older" directory and has not replaced
then with a newer version
(http://www.kernel.org/pub/linux/kernel/projects/rt/). This has
broken the ebuild its self, because it fails to download the patch. I
would say to fix it, but I can't even get the thing to compile and an
"alexMK" from the #lad/#ardour irc claims that he did tests and had
lower latencies with the unpatched 2.6.25-x kernel than the RT one.
This is the errors I got attempting to compile 2.6.25.8-rt7 (after
fixing the download URL in the ebuild):
CC kernel/sched.o
kernel/sched.c: In function 'sched_init':
kernel/sched.c:7702: error: implicit declaration of function
'global_rt_runtime'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
hav a look at this thread
quote from http://www.nabble.com/2.6.25.8-rt7-td18081945.html
I can avoid this failure, when I disable the "Group scheduling for
SCHED_RR/FIFO" menu entry. Don't know the impact.
/qoute
B. I've updated the 2.6.24 rt ebuild to 2.6.24.7-r17 (attached). It
was almost straight renaming it except that I changed the download URL
to grab it from kernel.org (or the new patch can be uploaded to
download.tuxfamily.org and the ebuild just renamed). I have thus far
compiled it without the fbsplash and also ran just src_unpack with
fbsplash to verify that the patch didn't fail or have any fuzzies, but
I haven't attempted to compile with fbsplash and I haven't tested the
-fbsplash just yet either.
I'll will add an updated ebuild later, thx
Greetz Frieder
C. I'm totally new to this DAW stuff on linux, so forgive me if I'm
stating the obvious. I'm guessing you guys are aware of the removal
of the preempting the big kernel lock in 2.6.26
(http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock). If I
understand the implications of this correctly, it will mean that the
2.6.26 kernel and beyond (for some time) will not be suitable for
low-latency applications and mingo is proposing a new "kill-BKL"
project that will probably be unstable for some time as well.
As a geek, I admit I'm slightly annoyed that the audio hardware (from
what I'm getting) seems to lack sufficient hardware buffers to wait a
few goddam milliseconds for it's interrupts to get serviced -- at
least, I presume that's why such a low latency kernel is needed, or
maybe I just lack appreciation of the levels of throughput required to
pull off reading and writing 24 tracks of digital audio at the same time.