[linux-audio-user] Re: [linux-audio-dev] [ANN] E-Radium V0.61b

From: Lee Revell <rlrevell@email-addr-hidden-job.com>
Date: Wed Jul 13 2005 - 20:01:03 EEST

On Wed, 2005-07-13 at 10:49 -0400, Eric Dantan Rzewnicki wrote:
> On Tue, Jul 12, 2005 at 07:34:07PM -0400, Lee Revell wrote:
> > On Wed, 2005-07-13 at 01:03 +0200, Florian Schmidt wrote:
> > > Some semieducated blabbering ahead (might be all wrong):
> > > I think i once read that interrupt handling "short circuits" the linux
> > > scheduler (in the sense that not only at every timer interrupt but also
> > > at the end of finishing any interrupt handler the kernel looks which
> > > processes are ready to run etc. and maybe there's a high prio process
> > > waiting just for that interrupt (by i.e. polling or reading on a device
> > > file).
> > > So for all those realtime processes that depend on events that are
> > > triggering interrupts (like soundcards' irqs) the timer interrupt really
> > > doesn't matter. I'm not sure at all though this applies to midi handling
> > > (and especially to alsa_seq when routing from one app to another) or is
> > > even correct in any sense at all :)
> > > Anyone can shed light?
> > Correct, it's not an issue for apps driven by hardware interrupts like
> > JACK, because the sound card consumes data at a constant rate. But for
> > MIDI or video where you have to periodically push data to the device it
> > matters.
>
> What is driving the kernel-devs to regress on this issue?
>

Saving battery on laptops. The only performance numbers anyone posted
indicated HZ=250 sped up a kernel compile on a 16 CPU machine (!) by
~5%, and this was after the fact. Not exactly compelling...

But since Linus and Andrew apparently all use laptops, us desktop people
are screwed...

Lee
Received on Wed Jul 13 20:15:36 2005

This archive was generated by hypermail 2.1.8 : Wed Jul 13 2005 - 20:15:37 EEST