After having a looong chat with the guys from linux4audio and reading tons of posts in ccrma forum, I must say .....

Idea with an rt-kernel for netbooks ....... DISMISSED .... it simply makes no sense.
Those guys mostly use gentoo and build their own kernel for years now and they gave me the following hints, that also can be found in discussions of other distributions:
1) the kernel (without preemption-patch) should have
Processor type and features >> Preemption Mode >> Complete Preemption (Real-Time)
Processor type and features >> Timer frequency >> 1000 HZ

General setup >> RCU Subsystem >> RCU Implementation (Preemptable tree-based hierarchical RCU)
 Proccesor Type and features >> Tickless System (Dynamic Ticks) should be excluded


Idea with multiple tasks .... DISMISSED ...... one task that installs drivers likje ffado and stuff like Jackit and sessionhandling and .... the other little stuff one needs, is a really good Idea.
(a big discussion should be held here on wich would be the best tools)
The rest, like LADSPA, DSSI, Soundfonts or apps like ardour, lmms ...... should not be included, it's simply too much.

We could provide a script that adds the content we need, like:
1) alter /etc/security/limits.conf
@audio - rtprio 99
@audio - memlock unlimited

2) add to /etc/rc.d/rc.local
echo 2048 >/sys/class/rtc/rtc0/max_user_freq
echo 2048 >/proc/sys/dev/hpet/max-user-freq

maybe add 2 new files to /lib/udev/rules.d
a) 40-rtc-permissions.rules with: KERNEL=="rtc0", GROUP="audio"
b) 40-hpet-permissions.rule with: KERNEL=="hpet", GROUP="audio"

On fedora ccrma, audio4linux and other forums, the musicians eaven do not use the RT-Kernel anymore since 2.6.33.
They report that it works better without the Preemption RT Patch with the stuff above and they get a really low latency (~ 2 ms) mit an old M-Audio 2496 without Jack XRUNS.

I tested these hints (exept compiling a kernel) today and it really works much better.
I could reduce the latency on my laptop with build in soundcard from 23.2ms to 5.8ms (44100 kHz)


2010/12/17 Romain d'Alverny <rdalverny@gmail.com>
On Fri, Dec 17, 2010 at 13:27, Michael Scherer <misc@zarb.org> wrote:
> Le vendredi 17 décembre 2010 à 12:35 +0100, Sascha Schneider a écrit :
>> [...]
>> Work to be done:
>> - provide sound packages like hydrogen, ardour, jackit ......
>> - provide TWO good realtimekernel, one for desktop and another for netbooks
>
> Given the fact that each kernel add a certain load on hdlists, I think
> we should really try to avoid their proliferation.
> ( kernel represent 33% of the size of contribs hdlist at Mandriva ).

This is not necessarily proliferation if it has a legitimate purpose
for the user needs. Maybe this could be merged with other existing rt
kernels.

If that makes for a really big issue for the final repository index
files in the end, then it may be a good reason to have a music studio
derivative distribution. Or find another solution?

you are right, too many kernels is not what makes it better.
 
>> - provide a script or someting like that, that scanns and adds sound
>> specific stuff to the limits.conf, /etc/udev/rules.d and /etc/rc.d/rc.local
>> and other places
>> - provide tasks files that really only install good and necessary sound
>> stuff.
>
> Good luck with deciding what is "good and necessary". You will always
> end frustrating people whose definition of good and necessary to be
> different.

Nothing will ever please everyone. But it's good to have a
recommandation/selection of whatever works best/best fits some
purpose, to avoid having to test everything everytime to have a
working setup; here a music studio.

This might be an idea, to simply provide an iso containing the basic setup like above with LXDE that uses the standard mageia repos for installation and updates.


So this may not be the best way to put it (using a rpm task), but it
looks like it. Having a basic recommendation set for a particular
purpose, on top of all available software in the distribution, does
not sound bad to me (further than that, having a way to
customize/store/retrieve this set).

Althought trying new stuff is great too, there are times you prefer to
focus on production and just install/restore tools that just works,
without taking too much time in this.

(we're not to the point of having something like a allmyapps.com
equivalent though).

> And secondary, I think we should also try to avoid having too much task-
> rpms. Their values is in the fact they allow to quickly install a set of
> rpm without searching in the whole set of rpm.

Indeed.


Romain
greetings, Sascha