Hi,
> > Are you sure you're not just missing a sound cue somewhere? I used to be
> > pretty sure about loop==-1 meaning "loop forever", and missing sound cues
> > definitely is the reason for SQ3 and QG1 sometimes (!) failing on
> > slowed-down systems.
>
> Here's my rationale:
>
> When you're moseying around inside the grabber in sq3, there are sounds
> that play when you go forward or backwards. Namely the hum of the motor
> (presumably a note-on, nothing else), and a recuring beep every second.
DoSound is called very often indeed...
> (I think I should hook my mt32 up to my dos box and have a look-see
> on the midi traffic...)
>
> Basically, one event gets sent for the "start hum", and one event is
> sent for EACH beep.
>
> So if it's loosing sound events, it's not loosing 'em in the sound
> server code. I'll add some more debugging output to the sound.c
> (and kernel.c) code to have it report every sound event that gets
> through, but my gut feeling is that it's never sending any STOP_HANDLE
> events at all.
Just in case we're talking about different things here: I'm not referring to
commands the sound client (interpreter) sends to the sound server; instead, I
am mostly referring to sound cues (and should have used that term), which
are sent the other way. Sorry for the confusion. We had a lot of problems
in the past regarding cues being missed; back when there was no sound server,
SQ3 and QfG1 blocked at the very situations you described.
OTOH, I don't think the sound server does very thorough checks with the data
it reads- more on that in the next mail...
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
iEYEARECAAYFAjqEHuMACgkQg4EAPSSqEf+NPwCffquQgdMtKcEfd34z+8P6rSGQ
POoAoIXQxARg/RNzEBF07BYa3sAJyKIN
=yWOw
-----END PGP SIGNATURE-----
