On Wed, Sep 18, 2002 at 01:26:39PM +0930, Alex Angas wrote:
> 1. Does this mean polling is no longer necessary?
Yes, actually. :) The "soundserver" wouldn't need to poll for
incoming events, as they'd all be applied immediately when they came in.
And then the main VM loop wouldn't need to poll for signals because when
the soundserver needs to do something, the call will modify the heap
directly.
> 2. Does this make sound playback completely independent from the FreeSCI
> core, apart from sending cues back to notify of song position and other
> necessary info?
Isn't this already the case?
My plan is to have a seperate "note playback" thread that does nothing
except play notes. Ideally, this would be combined with the song
iterators, as then we could just do things like "kill off the thread
playing that song and start up a new thread playing another song" and
the iterators would be in a sane satate if we were to resume 'em later.
> If this is all true then some problems with accurate timing would be
> solved on the Win32 side.
I thought the problems we were having with win32 were more to do with
timer accuracy than anything else..?
I'm working on a revamped version of the SDL soundserver; this way it'll
be fairly portable. And the nice thing is that we can abstract out the
thread calls into pthreads or anything else for that matter. :)
Currently it has no mutexes or thread synchronization thingeys at all.
We may eventually need spinlock protection for some things, but frankly,
SSCI has the same races going on.
I'm almost done with the "new" soundserver; pretty much all that I have
left is to make the "signals" apply to the VM directly. Next I'm going
to have to start making changes to the VM-side of things, mainly in how
it accesses the soundserver -- we no longer have a need for "bulk"
transfers, for example. Unfortunately, this is where I'll end up
breaking the existing soundservers, at least without a little
[re-]factoring.
I'll put up some tarballs once I have this in a state that approaches
functional.
I still have portability and reliability concerns, but that's the nature
of the beast with threading. My eventual goal is to abstract out ALL
threading calls into sci_thread_*, and those will map to system-native
stuff (SDL/Win32/pthreads/whatever). This way the various pcmout
subsystems will use the same thread library as everything else.
- Pizza
--
Solomon Peachy pizza@f*cktheusers.org
I'm not broke, but I'm badly bent. ICQ #1318344
Patience comes to those who wait. Melbourne, FL
Quidquid latine dictum sit, altum viditur
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9iH1sPuLgii2759ARAvDbAKDY+Jo5gytx7gpj42VOqrDnCHNTIgCg5uQU
4mg/WDrv0Mw7l+1Koju2djs=
=2p3k
-----END PGP SIGNATURE-----
