Hi,
> > The handles usually map to objects in SCI heap space. 0x0000 might mean
> > something special, but 0x75c0 is probably a bug of sorts- it might force
> > the referenced object's song to be loaded, or skipped quietly in SCI, or
> > something like that.
> Well, given that it happens (0x75c0 or whatever) every time you leave
> the text entry box, I'd think it is intended to un-pause the music
> playing..
Whatever it does is described by the sound command, not by the handle.
Sound events in FreeSCI consist of a triple (handle, command, parameter),
where 'handle' describes the heap address of an SCI object which contains
the number of one song as a property.
'command' is either what the sound server should do with the object
(if sent TO it), or a status message (if sent FROM it).
'parameter' is either ignored, or contains additional information.
The thing print here is 'handle'.
> > - message transfers are expected to be atomic on read() or write(), but
> > this isn't neccessarily true. This means that transferring sound
> > commands, events, or even status messages may break during transfer.
> > - message transfers use 'int's for some information. This defies one of
> > the points of having a separate sound server (possibility of running
> > it on a different system).
> Ah, the joys of IPC. :)
>
> So a new incoming event could interrupt one in progress? Wouldn't the
> the shared pipe thingey implicilty enforce synchronization?
Exactly. It's just a bad implementation on our side, no conceptual problem.
At least I hope so.
> What you
> write to one end will always come out the same order on the other end,
> and if it's in the middle of writing, say, 100k, a 5k transfer initiated
> before the first one is over will wait until the first one is over.
You shouldn't rely on pipes being able to contain 5k, though...
> Assuming that it's in the same execution thread, that is.. I'm not sure
> how thread-safe some of the system calls are, but write() strikes me as
> one that would be. :)
We're not multi-threading there (running a separate process, actually), so
thread-safeness is of no concern (fortunately ;-)
The problem is that, at least under heavy system load on Solaris, I'm getting
messages about sound events being crippled (Server->client). This is reported
(IIRC) only if select() returned success, but the following read() did not
read the number of bytes that make up a sound event.
> > Fixing both of these could be done simultaneously, and would clean up some
> > of the things in sound.c and soundserver_null.c that ought to have been
> > written differently in the first place.
>
> How wold you have written the soundserver?
Well, I was the one who wrote that part of it. If I could go back in time, I'd
tell myself to get the events right /now/ rather than postponing this. Also,
I'd politely ask myself to have a look at the return values of the write()
commands and handle partial read()s.
No, not really. If I could go back in time, I'd just tell myself a bunch of
lottery numbers and how to construct the time machine (to keep things
consistant).
> What are your feelings in scrapping the multi-process concept of
> the sound server and making it threaded instead?
I've been waiting for that suggestion ever since I committed that beast :->
> That way we wouldn't
> have to worry about transferring sound data, and having an event queue
> would be pretty trivial..
We already have one, BTW. The only problems with pipes overrunning might occur
with debug messages, but we don't get nearly enough of those that this seems
plausible.
> (and what *nix doesn't have an implementation
> of pthreads?)
Not all of them may have it installed, though...
> I do think the concept of a seperate sound server is sound, but it would
> really simplify things if it operated in the context as the rest of the
> interpreter. Along the same lines, there wouldn't be a translation
> between kernel events and sound events -- the queue would contain just
> the kernel sound events, and the soundserver itself would do the
Whoah, hold on- things aren't as easy as that....
> Hmm. I think I like where this line of thought is going.
Threads are powerful things, and like most powerful things, they make it a
lot easier and much more convenient to shoot your own foot. I want to stop
you from writing a pthreaded server, but I'd like to point out a few things:
1: I'd still like to be able to at least have the possibility to add a
separate sound server without breaking anything else later on. Not many
people are going to use that, but I don't think it would be too hard to
do that (leaving the possibility, not adding the server).
Alternatively, an architecture that extracts MIDI data and handles the
events separately would work fine- this way, we could forward data to
existing sound servers (YIFF, Rplay, ESD, aRTS- IIRC some of those don't
do MIDI, though) and track events locally.
2: You will need to store the events somewhere. Let's say the interpreter
runs in thread T_i, and the sound server uses thread T_s.
a) DoSound will only be called in T_i, but the information provided
there is needed in T_s, so we'll still need some kind of queue.
Since T_s will remove events, the queue will be written to from
both sides.
b) Any sound cues will be found in T_s. There now are two possibilities:
Either T_s queues the events (see 2.a), or it writes to the heap
directly to update the object in question.
However, SCI heap writes are not atomic, especially not on big-endian
and RISC machines (This is a performance issue we should look into for
the SCI01 VM redesign). This means that a context switch may leave the
heap in an invalid state, unless:
\alpha) Mutexes are used for ALL heap read/write operations
\beta) Queues are used for both sides
I'd strongly vote for \beta here.
In any case, mutexes will be required for the queues. So the final
result was that we exchanged:
- processes with pthreads
- FIFOs with hand-made queues
- read() and write() with custom hand-made queue operations using
mutexes
Summary: Using pthreads vs. separate processes:
Pro:
+ No need to explicitly copy song data
+ No need for a local song library
+ More portable to Win32
Contra:
- Threading might corrupt data all over the place rather than in a
few well-defined places
- More dependancies
- Needs queues on both sides
I'm not against using pthreads, but I don't think the gain will be as big
as you appear to believe. (Of course, I'd be happy to be taught otherwise
:-)
> (and that reminds me; I wonder how hard it would be to write a PC
> Speaker driver? Certianly easier than a MIDI one..)
I actually don't know about that. PC speaker stuff is stored as MIDI, too.
Dunno how /dev/whatever handles pc speaker output. It'd certainly be nice
to have support for that, though!
> > Whoah- that's weird. Entering the player name works fine for me, BTW.
> > The game freezing might mean that, somehow, you entered "menubar mode"
> > (where the interpreter is inactive). Is this always the case for you, or
> > only sometimes? Can you do other things in the player setup screen?
>
> I wasnt' able to do anything then. But right before my laptop battery
> tanked, I checked out a cleancopy of the tree devoid of my hacks, just
> in case something was up. I'll test it when I get to work and see how
> reproducible it is (and if changing the interpreter verion makes a
> difference)
OK, thanks!
llap,
Christoph
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjqEMC8ACgkQg4EAPSSqEf+/wQCfZT/1zzHVlvzlKhX7CCkziKpR
bdcAnRYoMU/IMl9V+XNlXOBW79w/hULp
=5UTu
-----END PGP SIGNATURE-----
