13 Jul
2005
13 Jul
'05
12:49 p.m.
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:
What is driving the kernel-devs to regress on this issue?
--
Eric Dantan Rzewnicki | Systems Administrator
Technical Operations Division | Radio Free Asia
2025 M Street, NW | Washington, DC 20036 | 202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
network(a)rfa.org.
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.