Interference between SOUND and Keyboard Input

[Hans Ruegg]

When SOUND is used repeatedly with short durations, it seems that
repeated keyboard input crashes the program.
I tested the following code while keeping a key pressed continually
from the beginning of program execution:

SOUND 512, 20
FOR i = 1 TO 40
  SOUND 1024, 0.5
NEXT i
PRINT "OK"
FOR i = 1 TO 40
  SOUND 256, 0.5
NEXT i
SOUND 512, 20
PRINT "ENDED"
END

Result: Nothing gets printed, and the program freezes (although in
the IDE I can still exit with Ctrl+Break). Sometimes the "OK" gets
printed, but afterwards the program freezes. (This happens only if
SOUND is in a loop, but not with several single SOUND statements
of longer duration.)
- I tried then to empty the keyboard buffer continually by putting
an INKEY$ insinde the loop:

SOUND 512, 20
FOR i = 1 TO 40
  SOUND 1024, 0.5: m$=INKEY$
NEXT i
PRINT "OK"
FOR i = 1 TO 40
  SOUND 256, 0.5: m$=INKEY$
NEXT i
SOUND 512, 20
PRINT "ENDED"
END

But the result was exactly the same as in the first example.

Does anybody know what is happening, and if there is a way to
avoid this problem?

Hans Ruegg

[Lance Edmonds]

Works ok for me with PB3.5 under Windows 2000... can anyone else duplicate Hans' experience?

Hans, what O/S are you using? If plain DOS, are there any device drivers or TSR's running?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Hans Ruegg]

I did the test under Windows 98 in a DOS box. Maybe I should try
also in DOS mode, but I cannot do this right now because I have
PB and internet connection in different places. I will post
again when I am able to do some more testing under different
conditions.

Hans Ruegg.

[Hans Ruegg]

I tested now in Windows 98 - DOS mode again. The result was the same:
When I keep a key pressed continually from the start of program exe-
cution, nothing gets printed, and the program freezes. The only diffe-
rence is that in DOS mode, after the program freezes, absolutely no
input is accepted, neither Ctrl-Break nor Alt+Ctrl+Del work.
No TSRs were present at this point, not even a mouse driver.

- Keyboard speed is another factor. I have my keyboard set to a rather
fast rate (over 30 repetitions per second) and to the shortest possible
delay (I think it is 0.25 seconds or less). I tested then with a slower
repetition rate (about 15 per second) and the program worked correctly.
There might be a very small chance that the keyboard buffer gets full before the second loop terminates even with the INKEY$ in the loop when repetition rate is very fast (the loop reads INKEY$ twice per timer tick or 36 times per second). But even a full keyboard buffer should not be a reason for a program to crash (using PLAY instead of SOUND never caused a crash when the keyboard buffer got full).

On the other hand, I found a workaround which works at least for my
special situation, where I do not want the program to react to any
input at all while playing sound: Before starting the sounds, I hook
Interrupt 9 with a handler which just reads the incoming keyboard data,
without processing it at all. When sound is finished, I restore the
original handler. This way the program works as expected. So it seems
the interference occurs only if the incoming keystrokes actually get
into the keyboard buffer.

Hans Ruegg