On Tue, Sep 11, 2001 at 01:30:49PM +0200, Christoph Reichenbach wrote:
> Still, right now we do queue them, and poll for them in a relatively large
> number of places. If we replace this simple poll by some time-based
> calculations, the result should be equivalent- provided that the queue is
> polled before and after every call to the Sound() kernel function (which
> we can guarantee).
We currently poll for sound cues at multiple places in the main
kernel/graphics loop.
I wrote a set of patches once, that only pulled sound events once per
tick. (ie 60Hz). Make that *delivered*. It would leave things on the
queue so that delivery would be spaced out. Should I revive that?
The actual "Do we have any waiting events?" check is conceptually very
low-cost.
The mechanism behind it can be nothing more than "is this flag set? if
so, pull on event off the stack"
> Actually, for FreeSCI sound servers, we could even guarantee synchronity
> in some way (within the limits imposed by the OS).
if we revert to an actual interrupt-driven mechanism, then yes, this'll
be relatively straightforward to guarantee.
- Pizza
--
Solomon Peachy pizzaATfucktheusers.org
I ain't broke, but I'm badly bent. ICQ# 1318344
Patience comes to those who wait.
...It's not "Beanbag Love", it's a "Transanimate Relationship"...
