Re: [linux-audio-dev] introduction & ideas

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] introduction & ideas
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 09 2002 - 18:57:04 EET


(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 -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Mar 09 2002 - 18:48:30 EET