#3804 closed defect (invalid)
DOTT: MIDI stuck after exploding cigar
| Reported by: | raziel- | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Day of the Tentacle |
Description
ScummVM 0.12.0svn (Jul 12 2008 07:07:53) Features compiled in: Vorbis FLAC MP3 zLib MPEG2
After Hoagie gives the exploding cigar to George W. and lights it, there is an explosion and right on the climax of the sound output (MIDI/MT32 hardware used) the MIDI output is stuck and a humming sound is all that is played after that. Changing screens or reloading a saved game doesn't cure it. I have to turn the MT32 off and on to get it working again, although only of i restart ScummVM in it's whole. Speech is working fine.
Day of the Tentacle (CD/English)
AmigaOS4 gcc version 4.0.2 (AmigaOS build 20051012)
Ticket imported from: #2016549. Ticket imported from: bugs/3804.
Attachments (3)
Change History (15)
by , 16 years ago
| Attachment: | tentacle.s08 added |
|---|
comment:1 by , 14 years ago
With the latest revision ScummVM 1.3.0svn54951 (Dec 18 2010 13:33:12) Features compiled in: Vorbis FLAC MP3 RGB zLib Theora i get 20 times the line
WARNING: Trying to use unsupported effect level value 64 in native MT-32 mode.!
AFTER loading the saved game and
8 times the same line
WARNING: Trying to use unsupported effect level value 64 in native MT-32 mode.!
after the cigar exploded.
On the MT-32 there is
7:Strings:Pizzicato
printed stuck on the display, but this is probably only the state where the hardware locked up.
A recurring hanging note can be heard until i completely take the hardware off the power. Reset (Master Volume + Part 5) is not possible as the hardware doesn't react to anything anymore.
Hope that helps a bit
comment:2 by , 14 years ago
| Owner: | set to |
|---|
comment:3 by , 14 years ago
This issue has probably been fixed with r55256, can you please check if it still occurs?
comment:4 by , 14 years ago
Unfortunately not fixed, but it changed behaviour
Now "1:Wind-2 |Sax 4" is stuck on the hardware display and the sound after the digar exploded sounds like it's following the flying cigar,say, it sounds like its playing an ascending curve with a low humming until it gets to the climax where it stays stuck and recurring.
Hardware is stuck again, need to hard reset
comment:5 by , 14 years ago
Right. Quite odd, to say the least. Thus this isn't related with the change to MidiParser
comment:6 by , 14 years ago
| Owner: | removed |
|---|
comment:7 by , 14 years ago
Not that i know what i'm talking about, but there seems to be either an overload on notes which are sent to the hardware producing an overrun (which would explain the completely hanging hardware) or there is a wrong command sent to it while the sound (non-MIDI) of the explosion is played resp. too fast sent, so the hardware cannot work with it/react to it.
Is there some way i can debug this?
comment:8 by , 14 years ago
ok, i (think i) found the cause of all of this.
My MT-32 device has the serial number 871166 which, according to Wikipedia (http://en.wikipedia.org/wiki/Roland_MT-32), is one of the "old" devices.
[quote] MT-32 (Old) LA32 sound generation chip is an 80-pin PGA. Control CPU is an Intel C8095-90 in ceramic DIP48 package. DAC is a Burr-Brown PCM54; the input signal having a resolution of 15 bits (see below). Line outs are unbalanced 1/4″ TS (L/R). No headphones jack. MT-32 with revision 0 PCB, used in units up to serial number 851399. The PGA LA32 chip is later replaced with a 100-pin flat type. MT-32 with "old-type" revision 1 PCB, used in units with *serial numbers 851400 - 950499.* [/quote]
On the same site Wiki mentions that "old" devices suffer in certain cases from a buffer overrun which results in the exact behaviour i'm getting in DOTT.
[quote] Compatibility problems
First generation units, having control ROM versions below 2.00, *require* a 40 millisecond delay between system exclusive messages. Some computer games which were programmed to work with the compatible modules (see above) or later ROM versions that do not require this delay, fail to work with these units, producing incorrect sounds or causing the firmware to lock up due to a buffer overflow bug, requiring turning the unit off and on. However, some games were designed to exploit errors in earlier units, causing incorrect sound on later revisions. Also, some games were written to use instruments not found in the MT-32 models, and require a compatible module, such as a CM-32L, for proper sound playback. [/quote]
I attached a commands list, read out while DOTT was running, with some seconds of MIDI playing before, while and after the lockup. (The list unfortunately does not stop at the offending command, because the data is still being sent while the hardware locked up already). I have yet to find a way to read the hardware's output.
Please, could any dev with knowledge of MIDI commands read the list and confirm or neglect that the commands are not sent with a 40 ms delay, but shorter?
The explosion and following lockup starts around the first "Control" command, line 409
Thank you very much
by , 14 years ago
| Attachment: | DOTT MT-32 Hardware Lockup_MIDI Commands.log added |
|---|
comment:9 by , 14 years ago
Adding a delay before _ICamd->PutMidi(_midi_link, data); in backends/midi/camd.cpp line 120 makes the lockup go away.
Due to the fact that i only need to set a delay of 1(!) ms to make it work (even setting it to 0 will work, but i'm unsure if it will work everytime) makes me think that such a delay is already in place somewhere in the source... Unfortunately i have no idea where.
I added a .diff to work around the lockup which is more or less a hack If someone with more insight in the audio parts please help me out here
Thank you
by , 13 years ago
| Attachment: | DOTT_MT-32_Hardware_Lockup_MIDI_Commands.diff added |
|---|
comment:10 by , 13 years ago
I re-added a (now hopefully useable) diff.
Could a dev please comment and if possible integrate? I have tested this and it does not break anything. N.B. it seems it only affects me anyway (even on my platform noone but me uses real MT-32 hardware) :-)
Thank you
comment:11 by , 12 years ago
Just to add the last bit of information i can come up before i get rid of this :-)
Right before the MT-32 is sent into hiatus there is a jingle played (which marks the start of the exploding cigar sequence) parallel to the normal MIDI background music.
The MT-32 hardware is not able to cope with such many notes and breaks (it is even stated in the MT-32 manual that some music pieces may need to be "OVERFLOW"ed) [quote] OVERFLOW ASSIGN o This function allows the MT-32 to generate MIDI notes beyond its capacity and send the excess out of the MIDI OUT port to the input of an additional external MIDI instrument. [/quote]
If one sets OVERFLOW on the hardware by hand before encountering the scene it will not break the MT-32 (missing second MIDI hardware will make that jingle vanish into nothing of course) and one can play along. (One needs to do this everytime the hardware is switched on, though...this is not really a solution or fix)
I will close this as Invalid as (i think) this is clearly a hardware limitation/bug and nothing ScummVM can do against it.
Feel free to reopen if anyone wants to add a workaround
comment:12 by , 12 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
give the cigar to georgie