On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote: > Some sort of comprimise has to be struck for now, until we get sub-HZ > timers. I'd prefer 100, personally (I had that set as default in my tree > for a long time). Some people would prefer 1000 or even more, maybe. > 250/300 seems like a reasonable comprimise to me. Exactly what problems > *does* it cause (in visible effect, not "timers are less granular"). > Jittery audio/video? How much worse is it?
OK, here's a real world example, taken straight from the linux-audio-dev list today. Lee Lee Revell <[EMAIL PROTECTED]> : > On Tue, 2005-07-12 at 20:57 +0200, Kjetil Svalastog Matheussen wrote: >> E-radium has been tested with both the 2.4 kernel and the 2.6 kernel >> and with a ~1GhZ machine and a ~2ghz machine. (A 2.4 kernel with a >> 100hz resolution timer will proably not work very nice though.) > > Can you please explain why 100HZ would be a problem for your app? Right > now the kernel people are trying to change the default HZ for 2.6 to > 250. I have told them that this is insane but they seem inclined to do > it anyway. > The program use poll to sleep. If the resolution of the kernel is 100Hz, there would sometimes be a too long delay of up to 10ms (and probably beyond) before the program is woken up, and before a midi message is sent, which can cause music to stutter. Simple as that. :-) > If you can provide more examples of apps that would be broken by this > change maybe we can convince them not to change it. > Hmm, mplayer I guess... Don't know how muse, rosegarden, seq24 etc. handles timing... But all midi-sequencers that doesn't use /dev/rtc could suffer. (?) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
