[LAU] Realtime latency kernel testing

[torbenh]

On Fri, Jan 07, 2011 at 02:43:27PM +0100, Robin Gareus wrote:
> On 01/07/2011 01:32 PM, torbenh wrote:
> > On Sun, Dec 12, 2010 at 07:22:28PM +0100, Jeremy Jongepier wrote:
> >> On 12/12/2010 06:42 PM, Ronald Stewart wrote:
> >>> Hi,
> >>>
> >>> I would go with what Robin said.  That being said, Robin's tweaks on
> >>> Transmission last year on 89 set the pace for our build (brilliant!).  Since
> >>> then tuning jack2 (jackdmp) Rui's rtirq, plus tuning for specific chips /
> >>> computer hardware makes a difference.  If you want something now that truly
> >>> stands up and has had some of the best Linux developers touch the project,
> >>> go with Transmission 4.2.  I know Paul will jump in and tune us all up with
> >>> our thoughts (go Paul!) but it should be stated again we are getting lights
> >>> out performance without RT on our new multi-touch Tablets for Pro Audio with
> >>> 2.6.35, Meego/AtomN450.
> >>
> >> So with 2.6.35 rtirq also works with a non real-time kernel?
> > 
> > i am not aware of normal kernels having threaded irq handlers.
> 
> No it they do not.
> 
> > additionally jack2 does not mlockall clients.
> 
> If the machine as enough RAM or no SWAP partition this won't be a problem.

hmm... with enough ram yes.
note that even without swap executable files are mmapped into the
processes addressspace, these pages can be dropped instantly, because
they already reside on disk. kernel likes doing that.

but with enough ram, you can assume most of the time, that ld.so faulted
the pages in, and they are going to remain mapped.

> 
> The ability to distribute audio load over multiple CPU cores is a big
> pro. (tschak was not packaged when building the Transmission disto and
> we were somewhat conservative, as well).

sure. if latency doesnt really matter, then that is the right choice.

> 
> > so basically i would say, that this configuration works is pretty much
> > luck.
> 
> Vanilla kernels > 2.6.33 do offer great overall performance: smooth
> Destkop and acceptable audio performance. Peak performance is for sure
> better than with the latest RT kernel (2.6.33.7.2-rt30).
> 
> However that it works _reliable_ is indeed luck.

RT is only about reliability :)

> 
> > maybe robin can clarify this.
> 
> I don't know the details for the new Indamixx tablets, maybe the
> sound-card (and USB ports for external audio interfaces) are on a
> dedicated IRQ (they were not on the first generation Indamixx netbooks:
> the audio IRQ was shared with the graphics card and WiFi; a RT kernel
> and rtirq was pretty much a requirement)
> 
> I don't think reliable low latency is a major goal for Indamixx. Most
> use-cases are quite fine with high latency that can be compensated for.
> 
> Also see an article I'm just writing with Luis:
> http://wiki.linuxaudio.org/wiki/jack_latency_tests#does_latency_really_really_matter

i know that latency doesnt really matter.
but for live FX and synths, it does matter.
thats probably a use case, which is not really used with transmission.

> 
> An occasional rare x-run is probably sth. Indamixx users can live with.
> After all it is a portable studio, not something super-pro-high-end to
> be mounted in a studio or used on-stage. Besides overall performance is
> for sure better than on comparable windows products even without RT kernel.
> 
> FWIW: Thomas Gleixer has announced that he's working on a RT patch for
> 2.6.37 but there's no ETA.
> 
> ciao,
> robin
> 
> >> Best,
> >>
> >> Jeremy
> >> _______________________________________________
> >> Linux-audio-user mailing list
> >> Linux-audio-user at lists.linuxaudio.org
> >> http://lists.linuxaudio.org/listinfo/linux-audio-user
> > 
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user

-- 
torben Hohn