The different realtime kernels

Thu Sep 30 16:55:41 BST 2010

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
> 