Hi,
> I'm not sure if it would be a good idea to dump the polled sound server
> entirely.
I agree; if we skip the possibility of invoking callbacks directly in the
main thread/process, the the two designs can cooperate easily.
> This is because when we implement the event-driven sound server,
> sacrifices may have to be made to do things 'The Microsoft Way' for the Win32
> platform. That is, after all, the main reason why the sound server needs to be
> changed.
Right now, I don't see any functional differences for looped sound servers
and the polled event transfer mechanism; for them, it's mostly a clean-up.
> That's why I'm a little concerned with the idea of calling a message function
> in the main process because that's far removed from how Win32 works. With that
> platform, messages are sent to the same thread or to another thread, and a
> callback function associated with each thread (where necessary), handles the
> messages.
Hmm, I'm afraid I can't follow you there- what's the problem there,
exactly?
There were two models I outlined for message-passing Win32, one (A) that
makes it look like a polled system from the POV of the kernel, and one (B)
that takes advantage of messaging to process cues slightly faster:
Model A:
Sound timing: Using delayed events
Main -> Server: Main: Sends message. Server: Processes message. Sends any
retour messages.
Server -> Main: Server: Sends message. Main: Puts message in message
queue.
poll function: Works as in other sound servers
Model B:
Sound timing: see A
Main -> Server: see A
Server -> Main: Server: Sends message. Main: Processes message immediately
and discards it
poll function: no-op, because queue remains empty
> I really don't like the idea, but it's possible that the architectural
> decisions we make for the event-driven sound server do need to allow for the
> best interests of Win32.
Hm, could you explain the problems in a little more detail, please? I
don't think I'm sufficiently bright to deduce them from what I know so
far...
llap,
Christoph
