Hi,
OK, I finally had a closer look now- what I said last time was from memory, and it seems to have been pretty lacking in terms of correctness. I must apologize for this. > In some parts of the code, there are calls to the sound_command() via > gamestate->sound_server->command(). In most others, a call to sound_command() > only is made, rather than through the game state pointer. Why? sound_server->command() seems to be the new, abstracted 'command' function. It seems to map to sound_command() in all cases. It could be mapped to something else, though, so calling sound_command() directly is no longer the correct approach- these calls should be considered to be bugs. > Why are some calls made to suspend (or resume) sound via > gamestate->sound_server->resume() and some to sound_command() with the > SOUND_COMMAND_SUSPEND_SOUND parameter? sound_suspend() and sound_resume() were originally convenience functions which seem to have made their way into the sound server API. Both are equal; I assume that the reason they were provided in this way was to allow implementors to use a different way to suspend the sound server (such as sending a SIGHLT). Again, this would mean that sound_server->resume() and sound_server->suspend() would be correct calls, althought the alternative should always be semantically identical (may have a worse performance or latency, though). > Sorry about the mix up. Aagh! No problem- sorry for me erring in my last mail! llap, Christoph
