>To have semi accurate delivery of video/sound/etc, you really need to
>know that user process will be notified (roughly) at a particular time,
>so using a timer is the only way I can think of to do this properly.

I guess it depends on which way you look at it... IMO, as the real VGA works
synchronously, you don't want to deliver video "at a specific time" but rather
"as soon as it's written to the video memory".  As soon as possible, anyway.
Sound is a different matter entirely.

>For video, a few times a second is good for now.  For sound, a little more
>will help.  We should make this a fmw.conf option.

Isn't this the other way around ?  After all, time can work through DMA buffers
and timing is not extremely critical.  However, the "real" VGA works
synchronously, things are displayed as soon as they get into the framebuffer.

>100hz is too frequent for now.  Though, if we make it a configurable
>option, then you could use it.  I saw mention of people interested
>in changing the Linux timer from 100Hz to 1000Hz,

(offtopic) I think this is a bad idea --- there's a HUGE amount of overhead
associated with that.  The scheduler I wrote uses variably-spaced timer
ticks (using mode 0 of the timer), but that's probably not suitable for
linux use.

>Just keep in mind, the way thing are currently done is a hack, since we
>don't support the IO mapped frame buffer yet.

Uhhhhh... what are you referring to ???

Ramon


Reply via email to