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, 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 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.... <div class="gmail_quote">2010/9/30 Ralf Mardorf <<a href="mailto:ralf.mardorf@alice-dsl.net">ralf.mardorf@alice-dsl.net</a>> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5">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 </div></div>PS: Pardon, it isn't good enough for all needs, but good for a lot of needs, hence we should use the rt-patch. <div><div></div><div class="h5"> > 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 <<a href="mailto:ralf.mardorf@alice-dsl.net">ralf.mardorf@alice-dsl.net</a>> > > > > 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 > > > > > > <a href="https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel" target="_blank">https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel</a> , which is > > > > more detailed and continuously updated). > > > > > > > > ***Summary*** > > > > vanilla = unpatched kernel straight from <a href="http://kernel.org" target="_blank">kernel.org</a> > > > > 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 > > <a href="mailto:Ubuntu-Studio-users@lists.ubuntu.com">Ubuntu-Studio-users@lists.ubuntu.com</a> > > Modify settings or unsubscribe at: > > <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users</a> > > > > > > > > > > -- > > Fagote / Contrafagote > > Bassoon / Contra-bassoon > > <a href="http://myspace.com/ricardolameiro" target="_blank">http://myspace.com/ricardolameiro</a> > -- Ubuntu-Studio-users mailing list <a href="mailto:Ubuntu-Studio-users@lists.ubuntu.com">Ubuntu-Studio-users@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-users</a> </div></div></blockquote></div> -- Fagote / Contrafagote Bassoon / Contra-bassoon <a href="http://myspace.com/ricardolameiro">http://myspace.com/ricardolameiro</a>