#1058 closed defect
COMI: Sound que buffer overflow
| Reported by: | fingolfin | Owned by: | aquadran |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
In various places of COMI, one gets a "Sound que buffer overflow". Maybe this is a real bug, maybe it means we simply have to increase the size of the sound queue.
I recently turned this into an error() to be able to better pinpoint it. In the scene where you first talk to murray, I got:
(11:2016:0x7AF9): Sound que buffer overflow (255 + 4 = 259)
Another thing I found out about this in the past: the overflow happens in a single scumm main loop iteration. I.e. first the queue is (almost) empty, then scripts are run, and boom, it overflows - processSoundQues is only called later. So it's definitely not a bug in processSoundQues, it must be either that our sound queue is too small, or some other issue (like we are not aborting a script when we should).
Ticket imported from: #775389. Ticket imported from: bugs/1058.
Change History (7)
comment:1 by , 21 years ago
comment:2 by , 21 years ago
I'm running scummvm-0.5.1-1 (RH RPM) and I can confirm this bug. The latest CVS didn't work either.
comment:4 by , 21 years ago
| Owner: | set to |
|---|
comment:5 by , 21 years ago
I wonder if aquadran's recent CVS commits in this area do help the issue? I just did a quick test, and wasn't able to reproduce the issue. But then again, maybe I just didn't try hard enough :-)
comment:7 by , 21 years ago
| Status: | new → closed |
|---|
Ther are two places this script invokes soundKludge:
The first looks OK to me, since it uses breakHere, giving the engine time to process: [02B8] (AF) startSound(localvar0) [02BE] (65) while (isSoundRunning(localvar0)) { [02C9] (B2) soundKludge([12,localvar0,1792,127]) [02E3] (B2) soundKludge([12,localvar0,1536,localvar3]) [02FD] (67) breakHere() [0303] (**) }
But the second one looks like this (ignore the invalid jump target, this is a bug in descumm. I manually checked the bytecode):
0396] (65) if (isSoundRunning(localvar0)) { [03A2] (B2) soundKludge([12,localvar0,1792,127]) [03BC] (B2) soundKludge([12,localvar0,1536,localvar3]) [03D6] (66) jump 397 [03DB] (**) }
This is a 'busy loop', it runs forever and never yields. No wonder the queue overflows.
Two possibilities: 1) maybe in COMI, soundKludge should work instantly 2) maybe this is a genuine script bug, and they just didn't notice. It should be possible to determine this using disassembly.