Hi,
On Sat, 6 Oct 2001, Alexander R Angas wrote:
> I'm getting close to getting this event SS working but have been a bit too
> busy to do much on it lately, sorry!
No need to apologize- we're all working on it in our spare time only.
> I was just having a look at sound.c and wondered why this was used and not
> everything done in soundserver.c? Why isn't s->sound_server->command() and
> its similar functions used for everything? Why do sound_command() and the
> other sound_XXX() functions need to be there (in sound.c) instead of calling
> everything through the sound server?
They don't need to be there, they just happen to be.
While the origins of this code are, in fact, historical, there are reasons
for this arrangement- after all, sound_command() does a bit more than
just pass on its parameters in a format that is more convenient for
the average sound server structure to handle: For commands that expect
a response, it waits and delivers the response to the caller (IIRC only
the sound server test function does that), and for 'load song' commands,
it retreives the songs in question and passes them on to the sound server.
It could certainly be argued that this functionality could also be
provided in separate helper functions.
> It just seems like double-handling and
> illogical to not have the sound server do everything instead of having bits
> of it split off.
Duplicating the functionality present in sound.c in every sound server
does not make much sense to me, so I believe that this is not what you
mean.
I assume that what you are suggesting is that the functionality invoked in
sound_command() should be split into smaller functions that would then be
called from sound server implementations, rather than the other way
around:
s->sound_server->command(STOP_SONG, handle, 0);
...
packet = snd_encode_packet(STOP_SONG, handle, 0);
...
packet.a := STOP_SONG; packet.b = handle; packet.c =0;
return packet;
...
write(fd, packet);
...
rather than
sound_command(s, STOP_SONG, handle, 0)
...
packet.a := STOP_SONG; packet.b = handle; packet.c =0;
s->sound_server->command(packet);
...
write(fd, packet);
(the 'get voices' and 'send song' commands would probably be the
only ones called from a separate helper function then).
Considering that your particular implementation does not care about packet
encoding, unlike the SDL and Unix sound servers, I think I can now
understand why you fail to see the point in this and would agree that it
makes sense to put this part of the sound_command function in a helper
function. The operations to get the number of voices (which also acts as a
test for whether the sound server works at all) would still have to be
taken care of, of course.
Is this what you were aiming at?
llap,
Christoph
