#1246 closed defect (fixed)
ALL: MT32: some notes cut off early
Reported by: | SF/logicdeluxe | Owned by: | SF/jamieson630 |
---|---|---|---|
Priority: | normal | Component: | Audio: MT32 |
Version: | Keywords: | ||
Cc: | Game: | Indiana Jones 4 |
Description
ScummVM 0.5.3cvs (Sep 25 2003 20:58:26) with the MT32 patch applied. Some notes are played shorter than they are supposed to do on a native MT32. I guess, this is due to wrong partial reserve setup. Is this even done in ScummVM? Unfortunately, I don't have a clue how to find out what exactly the original interpreter sets up there. Since the channels are allocated dynamically with the iMuse engine, setting the same partial reserve value to all channels might be a good idea. For example you can notice this in FOA in the Indy theme right after the LucasArts logo or in DOTT with the portamento notes when the LucasArts logo appears.
Ticket imported from: #812740. Ticket imported from: bugs/1246.
Attachments (1)
Change History (12)
comment:1 by , 21 years ago
Owner: | set to |
---|
by , 21 years ago
Attachment: | mt32-notes-cut-fix.diff added |
---|
comment:2 by , 21 years ago
comment:3 by , 21 years ago
Well, it works even better with partial reserve 4 instead of 3 so use that line instead: memcpy(&buffer[4], "\x10\x00\x04\x04\x04\x04\x04\x04\x04\x04\x04\x04\x48", 13);
comment:4 by , 21 years ago
Resolution: | → fixed |
---|
comment:5 by , 21 years ago
I've implemented your patch, with the modified partial reserve setting per your last post, and some other slight mods. I implemented an explicit delay after every transmission to ensure the MT-32 doesn't overflow, and I also reordered the init steps to try to use those delays to ensure that the ScummVM welcome message is up long enough to be readable. (I had reports in the past that it flashed for a split second and then disappeared as soon as program change messages started coming in.)
Please verify MT-32 behavior under latest CVS so that I know whether I got everything in properly. Thanks.
comment:6 by , 21 years ago
Something's wrong with it. Now, the MT-32 doesn't initialize at all. Not even the MIDI message LED indicates activity, which was the case before. The music is still playing, only the initialization is affected.
comment:7 by , 21 years ago
Sorry, I goofed in defining the conditions under which the init gets executed. Because it has delays in it now, I wanted to make sure it didn't get called unless we were actually in native MT-32 mode. Should be fixed in latest CVS.
comment:8 by , 21 years ago
Now it initializes, and I can clearly read the welcome message even with games starting with music immediately.
Well that line might be a better idea, because it sums up the partial reserves to 32: memcpy(&buffer[4], "\x10\x00\x04\x04\x04\x04\x04\x04\x04\x04\x04\x00\x4c", 13); The other might be a potential source for trouble and with this one I couldn't hear any differences in the games anyway. Seems like the MIDIs are composed with that setup.
comment:9 by , 21 years ago
Status: | new → closed |
---|
comment:10 by , 21 years ago
Okay, your tweak to the values is in CVS. Closing. Thanks for all the testing.
comment:11 by , 6 years ago
Component: | --Unset-- → Audio: MT32 |
---|---|
Game: | → Indiana Jones 4 |
I was able to fix this one.
This sets the partial reserve equally to all channel and so improves the performance a lot. Sounds pretty correct to me with it.
Also MT-32 master volume is set with this patch: The independent MIDI channel volumes already are scaled down acording to ScummVMs master volume so just ininialize the MT-32 to full volume. This is the same behavior the original interpreters do.
However, I encountered a limitation of the MT-32 here. See my FIXME comment! I'm not that familia with the entire ScummVM source, so I don't know, what the appropriate method is to do a short delay. I tested it with a short loop producing a bunch of warnings just to delay things a bit, and this solves the MT-32 execution buffer overflow problem. So it would be probably easy for you to fix this.