All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philipp Überbacher" <hollunder@lavabit.com>
To: linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: future of -rt kernels for realtime audio
Date: Tue, 06 Jul 2010 21:53:37 +0200	[thread overview]
Message-ID: <1278444945-sup-9886@eris> (raw)
In-Reply-To: <AANLkTikZNjYJnDM6iKgrT1230FP8DSMgHUrZz2lYL4ll@mail.gmail.com>

Excerpts from Pedro Ribeiro's message of 2010-07-06 13:19:31 +0200:
> Hi,
> 
> I've been using -rt kernels since 2.6.29 because I do realtime audio
> on my laptop.
> 
> The audio stability has been steadily improving since, and now I find
> that I can use 2.6.34 without the -rt patch and achieve the same
> stability as 2.6.33-rt - well, my latency requirements aren't that
> high, I just need to maintain 8.9ms completely stable, however before
> .34 it would be impossible without the -rt patch.
> 
> So out of curiosity, what changed for .34? According to [1], on .33
> Raw Spinlock Annotation was introduced in the mainline kernel.
> However, as said above, I can't get the same performance than with
> .34.
> 
> I remember that I read somewhere that the one the biggest problems
> with latency requirements was the use of the BKL. Do you think there
> will be a significant improvement of latency (in specific cases of
> course) with the scheduled removal of BKL for 2.6.36?
> 
> Thanks for the help,
> Pedro
> 
> [1] http://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html

Ah, nice to hear that the BKL removal is scheduled. Pretty much all I
know is that Linus set the BKL removal as precondition for preempt-rt to
be merged with mainline.
I guess this means that preempt-rt could disappear in some post-.36
version. I won't hold my breath.
Anyway, the stock kernel has been good for a while, but there are some
cases where I still experience big differences. Some, mostly audio
unrelated, actions or kinds of load cause lots of xruns with the stock
kernel and none with -rt. Prime example for me is xrandr, enable an
external monitor -> xruns, not so with -rt. There are a couple of other
cases. It's mostly about this kind of stuff, the achievable latency is
pretty much the same in my experience (which is only with an USB
interface).
-- 
Regards,
Philipp

--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2010-07-06 19:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-06 11:19 future of -rt kernels for realtime audio Pedro Ribeiro
2010-07-06 11:49 ` Robin Gareus
2010-07-06 15:45 ` Mark Knecht
2010-07-06 19:53 ` Philipp Überbacher [this message]
2010-07-06 20:44   ` Pedro Ribeiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1278444945-sup-9886@eris \
    --to=hollunder@lavabit.com \
    --cc=linux-rt-users@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.