Hi,
On Thu, 25 Oct 2001, Alexander R Angas wrote: > To be done after CVS move completed. A summary of what has been previously > described. > > Stage 1: > - Put common sound server functions as they currently are into soundserver.c/ > soundserver.h (note: some listed below are already present and may just be renamed). > > - int ticks_to_milliseconds(unsigned int ticks) While this function is- theoretically- valid, I don't think it _should_ be used. We already have a function song_sleep_time(l, t) in soundserver.c, where l is the GTimeVal of the time last slept and t is the number of ticks to sleep- this function returns a GTimeVal containing the number of seconds and microseconds that need to be slept until the next call should be made (remember that you'll typically call the sleep() function- or trigger its equivalent- after you've done some stuff (taking d microseconds), so the amount of time you'd like to sleep is d less than what ticks_to_milliseconds() would return to you. > - void init_handle(int priority, word song_handle) > - void play_handle(int priority, word song_handle) > - void stop_handle(word song_handle) > - void suspend_handle(word song_handle) > - void resume_handle(word song_handle) > - void renice_handle(int priority, word song_handle) > - void fade_handle(int ticks, word song_handle) > - void loop_handle(int loops, word song_handle) > - void dispose_handle(word song_handle) > > - void change_song(song_t *new_song) > - void change_instrmap(int action, int instr, int value) > - void set_mute(int channel, int mute_setting) > - void set_master_volume(guint8 new_volume) > - void set_reverse_stereo(int rs) > > - void stop_all() > - void suspend_all() > - void resume_all() > > - void sound_check(int mid_polyphony) > - void print_channels_any(int mapped) > - void print_song_info(word song_handle) These also need a "sound server state" type as a parameter, since they cannot access what used to be the sci0_soundserver() function's local variables. Other than that, it's a good idea indeed to split up this functionality into a bunch of functions. Using a separate 'reverse stereo' function seems acceptable, too. Note, however, that it should _not_ be the sound server implementation's job to call each of these functions individually- usually, implementations will be able to somehow determine one of the function constants defined in soundserver.h, so this should happen in a function "process_action()" or whatever that just consists of a big switch() statement calling these. > - Test, CVS commit, test. That's the point where I'll start merging it with the UNIX soundserver and start complaining. ;-) > Stage 2: > - Move current polled sound server into polled_soundserver.c. > - Make it use the common sound server functions. > - Test, CVS commit, test. OK. > Stage 3: > - Add event_soundserver.c. > - Interface exactly like the polled sound server. > - Uses common sound server functions. > - Test, CVS commit, test. > > > Stage 4: > - Add event_soundserver_win32.c. > - Uses the same sound server interface as current soundserver_xxx.c plug-ins. > - Test, CVS commit, test. > > Does this sound acceptable? That sounds OK, as far as I can tell (with the caveats listed above, I hope I haven't forgotten anything). As far as sound is concerned: I've started working on an 'iterator object' style reader for songs, this should help with cleaning up the sound code a bit more (and also to make it easier to integrate with the SCI01/SCI1 sound resources later on). The only new _functionality_ will be some experimental pcm detection/reader code; up to SCI01, all PCMs are stored in sound resources, so we might as well handle them in the sound server (might not be the ideal approach, but that depends on what exactly the pcm interface will end up looking like). llap, Christoph
