The different realtime kernels

Ralf Mardorf ralf.mardorf at alice-dsl.net
Thu Sep 30 17:44:23 BST 2010


On Thu, 2010-09-30 at 17:15 +0100, Ricardo Lameiro wrote:
> I agree with you. I think the best compromise is to use the Hard RT
> kernel patch on top of vanilla kernel, and have the Generic kernel for
> everyday usage.
> You can choose which kernel to boot from at the beginning,

I only use vanilla + rt-patched kernels for audio-video and everyday
usage. The only difference is the CPU frequency scaling. For everyday
usage I set it to ondemand and for audio-video work to performance and
sometimes I manually enable hr timer when doing MIDI work.

IMO just a kernl-rt is needed, but as I mentioned before, people running
32-bit architecture might need a patch to enable usage of large RAM.

But indeed, GRUB is our friend, we are free to use several kernels. OT:
GRUB is a little bit more user-friendly than GRUB2 is ;).

> Hard RT kernel, should be the only one to be supported, since it is
> the kernel that brings more benefits to audio/video production, If we
> spread attention with 2 more kernel flavours, no one can support it,
> and lets face it, abogani makes a hell of a good job, so we should
> simplify is life :D

Hm, on my Ubuntu Studio, neither Abogani's, anyone else or my own build
kernel-rt are ok :(. I can't boot any kernel-rt.

I'm able to run Suse with my self build kernel-rt, but not with the
repositories once and I'm able to run 64 Studio (Hardy, Karmic) with
kernel-rt from the repositories and self build kernels.

Live CDs, e.g. AV Linux are ok with the kernel-rt.

Anyway, the rt-patch could be a PITA, while the PREEMPT only kernel for
Ubuntu Studio is ok on my machine, as far as a PREEMPT only kernel is
able to do some jobs, but I'm able to boot the kernel.

IMO we only should take care of the kernel-rt and no other kernel.
Hard disk drives today are less expensive so everybody should be able to
install a distro for audio-video usage and if needed other distros for
other usages, because not only the kernel makes a different. IMO a DAW
e.g. don't need the security that's needed for some other usages.

I'm running several Linux, no Windows, on my 2 core AMD 64-bit PC, for
everyday usage and audio-MIDI productions, all Linux with kernel-rt
only, excepted Ubuntu Studio, because I didn't had the time to
troubleshoot why I'm unable to boot a kernel-rt for Ubuntu Studio.

I prefer 64 Studio, but I really like Suse and Ubuntu Studio too, of
course there are some other good distros, but those three are my
favourites, even if Ubuntu Studio until today isn't ready for
production.
I like the concept of Ubuntu Studio, excepted of the default PREEMPT
kernel, without rt-patch.

This are just my personal 2 cents, the advantage of Linux, that we do
have a lot of different paths we could go, even if it sometimes seems to
be a disadvantage.

> 
> Hard RT  kernel (Ingo Molnar Patch) and an alternative (generic) for
> everyday usage if wanted. 
> 
> I reinforce the idea, that maintaining 3 different kernels is a very
> difficult task to acomplish, and more with the scarce resources
> available (humman and finacial) let alone the spinout distros that are
> popping out on top of the project....
> 
> 2010/9/30 Ralf Mardorf <ralf.mardorf at alice-dsl.net>
>         
>         On Thu, 2010-09-30 at 17:45 +0200, Ralf Mardorf wrote:
>         > Hi Ricardo :)
>         >
>         > sorry for my broken English, especially at the moment,
>         because I do have
>         > an influenza.
>         >
>         > On Thu, 2010-09-30 at 16:18 +0100, Ricardo Lameiro wrote:
>         > > Hi Ralf,
>         > >
>         > > I didn't understood what did you meant with:
>         > > > For what do multimedia users (producers, but consumers)
>         need more,
>         > > but
>         > > > vanilla + rt-patch? Does somebody run a multi-user data
>         server on
>         > > the
>         > > > same machine, as he is using in his audio or audio-video
>         studio?
>         > > This
>         > > > would be nonsense.
>         > >
>         > > What would be nonsense? audio producers using hard RT
>         preemption on
>         > > the kernel?
>         > > Do you think that a webserver needs more Realtime
>         preemption than
>         > > audio work?
>         >
>         > No, I guess for audio and audio-video productions we only
>         need a vanilla
>         > + rt-patch kernel and nothing more.
>         >
>         > Nobody should run a web-server or anything else on a DAW, so
>         there are
>         > no other kernel patches needed.
>         >
>         > I'm pro PREEMPT RT and against PREEMPT only ;) or any kernel
>         patches
>         > that don't make sense for audio, audio-video productions.
>         >
>         > I was asking for reasons to patch a kernel with something
>         like a
>         > 'generic'-patch. A DAW, resp. audio-video-MIDI workstation
>         don't need a
>         > special server-kernel, or desktop-kernel etc., just a
>         vanilla kernel +
>         > rt-patch.
>         >
>         > Why does Ubuntu Studio comes without PREEMPT RT, but just
>         PREEMPT?!
>         > This is my intension.
>         >
>         > FWIW, I'm a professional audio and video engineer and did
>         program oldish
>         > computers and I'm missing hard real-time for modern PCs.
>         Even the
>         > kernel-rt isn't able to do hard real-time, so I don't
>         understand why
>         > Ubuntu Studio does prefer a kernel without rt-patch. Today
>         the rt-patch
>         > isn't good enough
>         
>         
>         PS:
>         
>         Pardon, it isn't good enough for all needs, but good for a lot
>         of needs,
>         hence we should use the rt-patch.
>         
>         
>         > and any kernel without this patch is useless for
>         > multimedia production.
>         >
>         > So a misunderstanding ;)!
>         >
>         > >
>         > > As I see, If a webserver used a RT kernel, it would have a
>         lot of
>         > > problems, because it will probably lock in some tasks
>         until they are
>         > > finished.
>         > >
>         > > Audio needs a very low latency, high resolution timer etc,
>         because the
>         > > Interrupts given by sound cards and by audio software need
>         to be
>         > > addressed as fast as possible,
>         >
>         > This is what I'm thinking off, I sometimes use the hr timer,
>         that on
>         > Linux still is a PITA on some machines and for some apps.
>         >
>         > Anyway, if possible a multimedia distro should use hr timer
>         (HPET), but
>         > always a kernel-rt only.
>         >
>         > >  if they arent, what happens is that the audio buffers,
>         either for the
>         > > souncard playback, or capture will run out of data, and
>         then the
>         > > continuos steam of audio data will be over, and wait until
>         receive
>         > > more info. In a Nutshell, you LOSE audio data, and you
>         will never get
>         > > it back, for professional audio that is unacceptable. Also
>         if You give
>         > > software RT priorities, it less possible that, for
>         instance, Ardour is
>         > > left behind of a twitter client.... unaceptable to...
>         > >
>         > > I am going to make some simple math with a not so
>         professional cenario
>         > > to ilstrate just the data stream, not audo software CPU
>         time.
>         > >
>         > >
>         > > Recording and monitoring out 8 channels (8 in 8 out) at
>         48KS/s at 24
>         > > bits
>         > >
>         > > 48000 * 24 = 115200 bps = 14.0625KB/s
>         > >
>         > > 14.0625 * 16 = 225 KB/s = 1.76MB/s
>         > >
>         > > Well, 1.76 MB/s is not to much really, well this calc is
>         simple
>         > > cenario, provided that the sound card uses real 24 bit
>         audio data
>         > > stream, if it used 32 bit, welll do the math.
>         > >
>         > > Now to a PRO setup.. 192 KS/s @ 24bits
>         > >
>         > > 192000 * 24 = 4608000 = 0.55 MB/s
>         > >
>         > > 0.55 * 16  = 8,78 MB/s
>         > >
>         > > 8.78 MBytes per second, not mbits, FIrewire is rated at
>         400 MBit per
>         > > second... USB in practice is a lot less + Communication
>         overhead.
>         > >
>         > > This is only on the Audio tranfer side, then you need to
>         send this
>         > > streams from each different software, make dsp
>         calculations for
>         > > Amplitude (volume) or mixing. This takes time.... so YES a
>         Real time
>         > > kernels is better for audio users than for normal users.
>         Specially if
>         > > you use Externals Firewire/USB card with high outputs
>         > >
>         > > note: this are simple calculations made fast, just to
>         demonstrate the
>         > > kind of stream we talk about. I assumed 24 bits, this is
>         very rare,
>         > > usually it goes with 32 bit, that is a lot more data to
>         transfer.
>         > >
>         > > If some more explanation on why a RT kernel is prefered
>         for audio, i
>         > > can try to answer some more questions, i am not a pro in
>         this tough.
>         > >
>         > > Ricardo Lameiro
>         > >
>         > > 2010/9/30 Ralf Mardorf <ralf.mardorf at alice-dsl.net>
>         > >
>         > >         On Thu, 2010-09-30 at 16:38 +0200, Ralf Mardorf
>         wrote:
>         > >         > On Thu, 2010-09-30 at 07:35 -0400, Ronan Jouchet
>         wrote:
>         > >         > > Hello everybody,
>         > >         > >
>         > >         > > Many are confused about the various realtime
>         kernels, so
>         > >         here is a
>         > >         > > reminder of the situation as of Sept. 2010
>         (but _please_
>         > >         see
>         > >         > >
>         > >
>         https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel , which is
>         > >         > > more detailed and continuously updated).
>         > >         > >
>         > >         > > ***Summary***
>         > >         > > vanilla = unpatched kernel straight from
>         kernel.org
>         > >         > > generic = vanilla + ubuntu sauce (it's the
>         default ubuntu
>         > >         kernel)
>         > >         > >
>         > >         > > The *soft realtime kernels, prepared by
>         changing
>         > >         build-time parameters*
>         > >         > >      preempt = generic + mild configuration to
>         reduce
>         > >         latency
>         > >         > >      lowlatency = generic + aggressive
>         configuration to
>         > >         reduce latency
>         > >         > >
>         > >         > > The *hard realtime kernels, prepared by
>         applying a big
>         > >         patch* from Ingo
>         > >         > > Molnar to the kernel source before building:
>         > >         > >      realtime = vanilla + patch (hard to
>         maintain and
>         > >         stabilize because
>         > >         > > merging 2 pieces of code is never easy)
>         > >         > >      rt = generic + patch (even harder to
>         maintain and
>         > >         stabilize because
>         > >         > > merging 3 pieces of code is harder than 2)
>         > >         > >
>         > >         > > ***Availability***
>         > >         > > - for Maverick, generic will be the only
>         kernel in the
>         > >         archives, thus
>         > >         > > the default kernel for ubuntu and
>         ubuntustudio, but
>         > >         Alessio has been
>         > >         > > maintaining a PPA providing lowlatency and
>         realtime
>         > >         > > - for Natty or later: work is being done to
>         include
>         > >         lowlatency in the
>         > >         > > official archives and make it the default
>         ubuntustudio
>         > >         kernel
>         > >         > >
>         > >         > > I hope this clears some doubts. By the way,
>         this confusion
>         > >         is only going
>         > >         > > to get more intense at release time (less
>         informed /
>         > >         technical users).
>         > >         > > Could we include some kind of note informing
>         users about
>         > >         this? Why not a
>         > >         > > "RealTime kernel help" item in the Audio
>         Production menu,
>         > >         redirecting to
>         > >         > > the wiki page?
>         > >         > >
>         > >         > > Good day,
>         > >         > >
>         > >         > > -- Ronan Jouchet
>         > >         >
>         > >
>         > >         >
>         > >         > 2 cents,
>         > >         > Ralf
>         > >
>         > >
>         > >         PS: Ok, on 32-bit architecture some might need
>         support for
>         > >         large RAM in
>         > >         addition, this might be an additional patch, hat's
>         not needed
>         > >         on 64-bit
>         > >         architecture.
>         > >
>         > >
>         > >
>         > >         --
>         > >         Ubuntu-Studio-users mailing list
>         > >         Ubuntu-Studio-users at lists.ubuntu.com
>         > >         Modify settings or unsubscribe at:
>         > >
>         https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users
>         > >
>         > >
>         > >
>         > >
>         > > --
>         > > Fagote / Contrafagote
>         > > Bassoon / Contra-bassoon
>         > > http://myspace.com/ricardolameiro
>         >
>         
>         
>         
>         --
>         Ubuntu-Studio-users mailing list
>         Ubuntu-Studio-users at lists.ubuntu.com
>         Modify settings or unsubscribe at:
>         https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users
>         
> 
> 
> 
> -- 
> Fagote / Contrafagote
> Bassoon / Contra-bassoon
> http://myspace.com/ricardolameiro





More information about the Ubuntu-Studio-users mailing list