Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#3404 closed defect (fixed)

LOOM/FLAC: Pauses (temporary lockups) after speech

Reported by: (none) Owned by: fingolfin
Priority: normal Component: Engine: SCUMM
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)

flac-loop-fix.patch (1.1 KB ) - added by fingolfin 12 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 by eriktorbjorn, 12 years ago

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.

comment:2 by fingolfin, 12 years ago

Owner: set to fingolfin

comment:3 by eriktorbjorn, 12 years ago

What is the status of this item?

comment:4 by (none), 12 years ago

It still happens with r29537, if the question was addressed
to me, if not, just ignore me :-)

comment:5 by fingolfin, 12 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 eriktorbjorn, 12 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:7 by (none), 12 years ago

Flac 1.2.1 here

comment:8 by fingolfin, 12 years ago

Summary: LOOM/FLAC: Pause after iventory driven actor commentLOOM/FLAC: Pauses (temporary lockups) after speech

comment:9 by sev-, 12 years ago

What is the status of this item?

comment:10 by eriktorbjorn, 12 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 fingolfin, 12 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:12 by sev-, 12 years ago

What is the status of this item?

comment:13 by raziel-, 12 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 eriktorbjorn, 12 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 eriktorbjorn, 12 years ago

However, when I threw away my entire ~/.scummvmrc and added the game, the problem went away. Very weird.

comment:16 by raziel-, 12 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 eriktorbjorn, 12 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 raziel-, 12 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 eriktorbjorn, 12 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 fingolfin, 12 years ago

Attachment: flac-loop-fix.patch added

comment:20 by fingolfin, 12 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:21 by fingolfin, 12 years ago

Torbjörn confirmed this to be fixed.

comment:22 by fingolfin, 12 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.