#3404 closed defect (fixed)
LOOM/FLAC: Pauses (temporary lockups) after speech
| Reported by: | (none) | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Loom |
Description
ScummVM 0.11.0svn (Sep 16 2007 09:25:15) Features compiled in: Vorbis FLAC MP3 zLib MPEG2
In Loom there is a long pause after every event driven actor comment (speech). Whenever the actor (or the narrator for that matter) talks a line the cursor gets stuck for approx. 15 seconds and gets freed again. One can play along, but it happens with every line which make the game kind of hard to play.
e.g. The narrator in the very first screen says: "Please choose your skill level" followed by the pause.
Bobbin on giving a comment when looking at the sky in the followup screen causes the same pause aswell as "There's an owl in there" when looking at one of the tree holes.
I dunno if it happened with earlier builds as this is my first try on FLAC encoded audio tracks, though it doesn't happen with Indiana Jones and the Last Crusade (FM-Towns) nor with playing the tracks on an audio player. They seem to be fine.
Loom (CD Talkie/English)
AmigaOS4 gcc version 4.0.2 (AmigaOS build 20051012)
No savegame as it happens right from the start and is reproduceable (at least here)
Ticket imported from: #1795755. Ticket imported from: bugs/3404.
Attachments (1)
Change History (23)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
| Owner: | set to |
|---|
comment:4 by , 17 years ago
It still happens with r29537, if the question was addressed to me, if not, just ignore me :-)
comment:5 by , 17 years ago
On my PowerBook running Mac OS X 10.4.11, I can't reproduce this neither with FLAC 1.1.1 nor with FLAC 1.1.3.
comment:6 by , 17 years ago
Perhaps it's limited to FLAC 1.1.4 and later? I see the latest version is 1.2.1, and I can't help but wondering what they broke this time...
comment:8 by , 17 years ago
| Summary: | LOOM/FLAC: Pause after iventory driven actor comment → LOOM/FLAC: Pauses (temporary lockups) after speech |
|---|
comment:10 by , 17 years ago
Unchanged, I suppose. I no longer have FLAC 1.1.4, but it still happens with FLAC 1.2.1.
comment:11 by , 17 years ago
And I can't install FLAC 1.2.x at this time, so I have no way to reproduce it for the time being. That might change once I find the time to finish setup of my cross compilation environment, though.
comment:13 by , 17 years ago
ScummVM 0.12.0svn (Dec 31 2007 11:15:55) Features compiled in: Vorbis FLAC MP3 zLib MPEG2
Well, it seems ot be fixed (at least for me)
The lockups occured at once after i build the exe, but funnily not with my test exe (no options, no modern style gui, no pathes set and so on), so i dig deeper to see what it kept from working on my normal build.
Seems it was a combination of obsolete engine name (i used "loom" instead of "loom-vga" for ages) and obsolete and/or broken options in the .ini file.
After updating all of the Option pages (saving them again to the .ini file) and setting the engine name to loom-vga, this specific error never occured again.
Would be nice to have a comment from Torbjorn too.
Have a great new year everyone
comment:14 by , 17 years ago
Re-adding the game (to make sure the game entry is set up properly) makes no difference for me.
My old Loom entry looks like this:
[loomcd] description=Loom (CD) path=/usr/local/games/scummvm/loomcd/ gameid=loom
Re-adding the game, I get this:
[loom-vga] description=Loom (VGA/DOS/English) path=/usr/local/games/scummvm/loomcd/ platform=pc gameid=loom language=en
In both cases, the "gameid" is still "loom".
comment:15 by , 17 years ago
However, when I threw away my entire ~/.scummvmrc and added the game, the problem went away. Very weird.
comment:16 by , 17 years ago
I meant the ones in brackets, sorry
I have the same descriptor as you know (loom-vga) and was about to propose the deletion of your scummvm.ini :-)
Thats one strange behaviour there :-o
comment:17 by , 17 years ago
I'm not 100% sure, but it seems what made the difference is whether my output sample rate is set to 22050 Hz (works) or 44100 Hz (hangs temporarily).
comment:18 by , 17 years ago
No change if i choose 22050 over 44100 (my preferred setting anyway). Both work now after a completely new "game add".
Hmm
comment:19 by , 17 years ago
I took another look at this, and here's what seems to be happening:
FlacInputStream::readBuffer() is called, requesting 8192 samples. (If ScummVM has to resample the sound, it only asks for 512 samples at a time.)
Since _lastSampleWritten is still false, it enters the loop
while (_requestedSamples > 0 && state == FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC) { ... processSingleBlock(); ... }
At some point, FlacInputStream::callbackWrite() determines that it has read all the samples it needs from the file:
if (_lastSample != 0 && firstSampleNumber + numSamples >= _lastSample) { numSamples = (uint)(firstSampleNumber >= _lastSample ? 0 : _lastSample - firstSampleNumber); _lastSampleWritten = true; }
So _lastSampleWritten gets set to true, but for whatever reason _requestedSamples is still not zero so the while loop continues. The next time callbackWrite() is called, we're past the last sample and numSample is set to zero. That means _requestedSamples isn't modified at all this time, and the only thing that can stop the while loop is when the decoder state changes from FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC to (probably) FLAC__STREAM_DECODER_END_OF_STREAM.
Fingolfin, does any of this mean anything to you?
by , 17 years ago
| Attachment: | flac-loop-fix.patch added |
|---|
comment:20 by , 17 years ago
Thanks Torbjörn, that was very helpful! I hope that the patch I attaced below solves the problem. I'd be happy to get some feedback on it, though, as I can't reproduce the issue myself. File Added: flac-loop-fix.patch
comment:22 by , 17 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I can reproduce this on my Linux box, when looking at the sky ("It's dawn.") in the first room. I'm using the 1.1.4-3+b1 FLAC libraries from Debian unstable.
It seems like ScummVM gets stuck in FlacInputStream::readBuffer(). Specifically, in the while (_requestedSamples > 0 && state == FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC) loop. I'm not sure why.