(All of a sudden, I'm becoming interested in high resolution timers w/ scheduling capabilities in mainstream kernels... but not for reasons that have much to do with audio.)
On Wednesday 06 March 2002 11.46, Martijn Sipkema wrote: [...CLOCK_MONOTONIC...] > No, it doesn't accomplish this, but it can. The kernel will have to > support it, so Linux will have to gain accurate scheduling. In the > meantime I think getting the clock resolution on Intel from 10ms > down to 1ms will be sufficient in most cases. How likely is it that this will happen in mainstream Linux kernels? *heh* Then again, as it seems like the goal is to have properly working kernel preemption (required for real time, as well as high end SMP scalability), things like that actually start to become *useful* for real applications... After all, if games, audio applications and other multimedia applications are going to fight for the RTC, and then hog the scheduler with 1024+ Hz "wakeup rates", we have a problem. At that point, it would be a lot more efficient if those applications could just use high resolution software timers (driven by the programmable system timer, something like in KURT, AFAIK), programmed to wake threads up *only when required*, as opposed to "at an arbitrary rate, just high enough to do the job". Is this relevant to other applications than "professional MIDI applications"? Well, lets just say that, while most graphics cards seem to suck real bad when it comes to retrace synchronized h/w page flipping, I'm not going to sit and accept that only Windows can give you absolutely smooth scrolling and animation. When even *Windows* can handle animation as smoothly as game consoles and arcade machines, maybe it's time to at least start thinking about fundamental things like double and triple buffering with h/w page flipping, and retrace synchronized flips...? > > What is needed is an extraordinarily (by comparison with most > > systems) high resolution timer. This can only be provided by (1) > > a device like the timer on the old GUS boards or (2) something > > like what the KURT patches do (constantly reprogram the system > > timer to interrupt when needed). > > > > Without them, I don't see how this can ever be done with the > > correct timing. I define correct to be the timing that would be > > obtained from a device driver that blocked all interrupts but its > > own, and had a queue of say 4kB of MIDI data that it delivered in > > an uninterrupted stream via a h/w MIDI port. > > I really don't think that's necessary. A <<ms accurate time should > be sufficient. Well, it all depends on your definition of "correct MIDI timing"... //David .- M A I A -------------------------------------------------. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-------------------------------------> http://olofson.net -'
