Re: RT patch acceptance

From: Lee Revell (rlrevell_at_joe-job.com)
Date: 05/28/05

  • Next message: Lee Revell: "Re: PATCH: "Ok" -> "OK" in messages" 
    To: Andi Kleen <ak@muc.de>
Date:	Sat, 28 May 2005 16:57:13 -0400

    On Sat, 2005-05-28 at 21:55 +0200, Andi Kleen wrote:
    > On Fri, May 27, 2005 at 03:53:10PM +0200, Ingo Molnar wrote:
    > >
    > > * Andi Kleen <ak@muc.de> wrote:
    > >
    > > > AFAIK the kernel has quite regressed recently, but that was not true
    > > > (for reasonable sound) at least for some earlier 2.6 kernels and some
    > > > of the low latency patchkit 2.4 kernels.
    > >
    > > (putting my scheduler maintainer hat on) was this under a stock !PREEMPT
    > > kernel?
    >
    > Yes. I did not run the numbers personally, but I was told 2.6.11+
    > was already considerable worse for latency tests with jack than 2.6.8+
    > (this was with vendor kernels in SUSE releases); and apparently
    > 2.6.8 was already worse than earlier 2.6.4/5 kernels or the later
    > and better 2.4s. CONFIG_PREEMPT in all cases did not change the
    > picture much. Sorry for being light on details; as I did
    > not run the tests personally.

    Um, that sounds 100% backwards. Starting around 2.6.8 the latency (as
    measured by the smallest usable jack buffer size) improved drastically
    with each release. Check the linux-audio-user or linux-audio-dev
    archives, many JACK users report that 2.6.10 or 2.6.11 is the first
    mainline kernel that gives acceptable performance at all. In fact,
    starting around 2.6.11 some pro audio users have been switching back
    from PREEMPT_RT to mainline as a result.

    Lee

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Lee Revell: "Re: PATCH: "Ok" -> "OK" in messages"

    Relevant Pages

    • Re: Confusing sound issues (ALSA, jackd, etc.)
      ... you can just run JACK and Ardour as a regular user. ... start it with jackd and don't elect to start with realtime set, ... > Differences abound, depending on kernel version, etc. ... The state of audio documentation is absolutely PATHETIC. ...
      (Debian-User)
    • Re: [PATCH] Realtime LSM
      ... On Sat, 2004-11-20 at 00:19 -0600, Jack O'Quin wrote: ... >> Any other objections to the patch? ... Well I am certain it works with the current kernel. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] [request for inclusion] Realtime LSM
      ... I made no changes to the kernel, ... That JACK scheduling test doesn't have any graphical component, ... cannot detect the problems of audio applications with GTK or Qt ... realtime with SCHED_FIFO scheduling. ...
      (Linux-Kernel)
    • Re: RT patch acceptance
      ... > But it's the only way to get practiallow latency benefit to ... > It is basically similar to why we often avoid kernel tunables - the ... advanced-audio (jack) users. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [Jackit-devel] Re: Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19
      ... On Thu, 2004-12-02 at 11:07 -0600, Jack O'Quin wrote: ... > Is printkguaranteed not to wait inside the kernel? ... > familiar with its internal implementation. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)