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 Changed 12 years ago by eriktorbjorn

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 Changed 12 years ago by fingolfin

Owner: set to fingolfin

comment:3 Changed 12 years ago by eriktorbjorn

What is the status of this item?

comment:4 Changed 12 years ago by (none)

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

comment:5 Changed 12 years ago by fingolfin

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 Changed 12 years ago by eriktorbjorn

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 Changed 12 years ago by (none)

Flac 1.2.1 here

comment:8 Changed 12 years ago by fingolfin

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

comment:9 Changed 12 years ago by sev-

What is the status of this item?

comment:10 Changed 12 years ago by eriktorbjorn

Unchanged, I suppose. I no longer have FLAC 1.1.4, but it still happens with FLAC 1.2.1.

comment:11 Changed 12 years ago by fingolfin

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 Changed 12 years ago by sev-

What is the status of this item?

comment:13 Changed 12 years ago by raziel-

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 Changed 12 years ago by eriktorbjorn

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 Changed 12 years ago by eriktorbjorn

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

comment:16 Changed 12 years ago by raziel-

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 Changed 12 years ago by eriktorbjorn

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 Changed 12 years ago by raziel-

No change if i choose 22050 over 44100 (my preferred setting
anyway). Both work now after a completely new "game add".

Hmm

comment:19 Changed 12 years ago by eriktorbjorn

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?

Changed 12 years ago by fingolfin

Attachment: flac-loop-fix.patch added

comment:20 Changed 12 years ago by fingolfin

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 Changed 12 years ago by fingolfin

Torbjörn confirmed this to be fixed.

comment:22 Changed 12 years ago by fingolfin

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