Hi, > (a) Signals - are these MIDI signals defined in the MIDI standard? If so, No, they're our own way of communication (sound.h, soundserver.h). We send 'commands' to the server, which replies with 'signals' whenever it thinks this is appropriate. > where can I find it? Or is there a list of them somewhere, how many are > there, and do we really need 6 bits for them? There are (IIRC) about 20 commands and 4 or 5 signals. 5 bits would be enough, of course, but I was careful with that number. > (b) You previously said in e-mails that: "Songs should be locked before > their pointers are sent, and only be unlocked if a 'SOUND_UNLOCK_SONG' (or > whatever) message is sent from the sound server to the main thread." > > Why can't the sound server unlock the song itself when it's finished with > it? Because the resource manager is not re-entrant, and may not even be in the same address space as the sound server (when running the proposed UNIX/SHM server, which would share only resource data). Regarding the first point: It'd be an unacceptable risk to have two threads working on the resource manager concurrently, unless we'd provide a mutex mechanism- but simply sending an "unlock song" command back seems easier and more general to me. > "Cues and song status information are sent from the process_timer_event() > function to the main thread." > > Where? I can't find it. Sorry! My mistake- put that into the future tense. It's supposed to describe how things will work with the new system (right now, they are send in the sci0_sound_server() by using functions provided by the sound server implementation). llap, Christoph
