Hi,
> > 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.
>
> Yes, I was thinking about that. At the moment I'm just using static variables in
> a .h file which isn't appropriate of course. There doesn't appear to be a sound
> server state struct at the moment - if that's correct I'll add one.
It's correct, as far as I know.
> > 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.
>
> That's correct. These are only called when a message gets sent to the event
> sound server, which hands it off to the appropriate function via a massive
> switch/if-else statement.
>
> As far as the polled sound server goes, I haven't looked at that. I was just
> going to put a call to the appropriate function whereever the actual code for
> that function currently is.
OK, but decoding the functionality is a generic interface issue; the
current interface definition states that each event transmission
operation passes a three-tuple (handle, signal, parameter) (the event) to
the sound server, where it can then be decoded; this means that
switch (signal) {
case SOUND_COMMAND_PLAY_HANDLE:
...
case SOUND_COMMAND_SET_LOOPS:
...
...
}
is common to each implementation (at first glance) and should therefore be
put into what I used to refer to as the "handle_command()" function (which
you _might_ want to bypass for your implementation, but which also needs
to be present for everyone else (at least for all alternative
implementations I can see so far...)).
[...]
> > 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).
>
> Is this the Sample Dump Standard (SDS) detailed in the link to the MIDI spec you
> sent me?
No, it's something proprietary Sierra made up (see the other recent mails
discussing PCM stuff for details, if you're interested).
> Also, several of the MIDI functions are not currently implemented (particularly
> the SysExs), I assume because SCI0 doesn't use them. Does this need to be done
> at some point?
As far as I can tell, the only thing we don't support yet are a few
control changes that occur occasionally (IIRC they're still passed to the
drivers).
> And another point, I notice that even under Linux the sound seems to be a little
> clunky. At least, it's not as smooth as the original Sierra games. Is there any
> known reason for this?
Hmm, I'm not sure; it seems to be working fine here (but I'm running with
HZ 1024 rather than 256, so this might be an issue here). Also, I don't
have access to any system where I can run the original games with sound
output, so I'm afraid that I cannot comment on that.
We're not using any real-time stuff, though (who'd want to run a game suid
root, after all?), so the sound quality depends on the total system load.
I'm running at a system load of 2.5 ATM, and everything sounds smooth and
right, though...
Were you using the timidity hack with OSS?
Has anyone else observed this?
llap,
Christoph
