Hi,
[Signal handler approach]
> I like this better from an architecural perspective, but implementation
> will be more difficult. The main game loop shouldn't care about asking
> the soundserver for events.
If we really want to favour asynchronous updates. Only doing updates in a
few controlled places also has advantages, particularly wrt debugging.
> And even under Unix, we could just use good ol' SIGUSR1/SIGUSR2 :)
Latencies for these are around 2ms on my box. It's not critical, but I
don't think using signals would give us an advantage in practice.
> One thing I'd like
> to do is get rid of the whole "song transfer" and have the soundserver
> itself load the sound resources off of disk. with PCM data, transfers
> can get quite large...
The original reason for doing the song transfers was to make it possible
to (eventually) run the sound server on a different box than the program
is running on, using remote socket connections. Nowaday's sound daemons
(esd, arts...) play complete MIDI files at best and PCM only at worst, so
they're not capable of dealing with our requirements (unless we separate
sound playing and cue tracking).
If we'd force the sound server to read from disk directly, we'd give up
this path. OTOH, our recent changes already make this problematic, as the
job of creating the midi and midiout drivers is currently left to the main
program, rather than to the sound server.
What we could do to serve both purposes would be to make the sound server
request songs, rather than to expect the client to supply them by default,
using another layer of abstraction to conceal the means used to pass the
song data- using shm, pipes, files in /tmp, a second resource manager, or
whatever is deemed appropriate.
llap,
Christoph
