> I can't test reasonably from here either (no sound output, everything > extremely slow).
I have ALSA working now so will be able to test! > > > I'm currently considering releasing with the sound server from two months > > > ago (leaving the current state in CVS), but I'm not sure how negatively > > > this would affect Win32. > > > > Performance under Win32 should be about the same. If it's polled, it doesn't > > work too well on this platform. :) > > OK, but I don't see how the event server could be integrated cleanly... I'm not following, isn't it already? The idea was to have the sound servers abstracted far enough so that they could use common functions except in exceptional cases. The problem under UNIX you mention below indicates that this could be difficult or largely impossible. But if it is possible, it would mean that fixes and additions to soundserver.c which contains the common ss functions would apply and work with both sound servers. That's what I've been aiming for. It's unfortunate that this doesn't seem to be working out. > > > - I'm not certain if the information we're storing on the sound server end > > > is sufficient (this might be the cause of the problems). If it is not, > > > savegame backward compatibility to this release will become a PITA. > > > > What extra information do you suspect may be required? > > Things like 'newsong', for example, but, again, I'm not certain; it's all > still rather unfamiliar to me. I managed to work out the threee song pointers when I converted the polled ss over to use the sound server state struct. modsong - gets a pointer to the song given by a new event's handle. modsong can become a new song, where it gets added to the song library. If it is to become a new song, newsong = modsong. newsong - starts in the loop as a pointer to the currently playing song. Any changes to the currently playing song occur when newsong gets assigned a new pointer. At the end of the loop, a changed newsong has newly initialised instruments. Also, song always becomes = newsong. If the newsong pointer never changed, then nothing changes; if it did change, then song gets the pointer to the song. song - the currently playing song. Song data is only sent from this pointer. It's pointer is left alone unless newsong gets a new pointer (see above). > As far as I understood your changes in this part of the code, you made > the server send a command to itself there- this won't work with the UNIX > sound server because it's using unidirectional pipes for this; the sound > server process only has the reader end of those (maybe the specs should > clarify that this does not have to be supported; I don't think that it'd > be really helpful to require it). I will remember this - can it be changed or do the pipes have to stay unidirectional? > You seem to have a function for this, maybe I should've used that > instead... Only because it's helpful for tracing. Cheers, Alex.
