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? 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, 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 <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 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 </div></div>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. <div><div></div><div class="h5"> -- 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>