You are not logged in

For the record: I tried with a chunksize of 32 bytes and it worked fine, even with the next commit. Only annoyance was an ERROR logged by FFMPEG decoder which I downgraded to a DEBUG with the next commit.

From launch to sound there are more things happening. It is known that gnash has a longer startup time.

In this case we have a single DEFINESOUND containing mp3 data.
In Gnash this is handled by EmbedSound and EmbedSoundInst.

Looking at the interface it looks like some work was started to do incremental decoding and it may possible to already do that by limiting inputSize variable in EmbedSoundInst::decodeNextBlock.
If you want to experiment with that I hope the above is useful.

This SWF contains a very large DefineSound tag. Gnash's EmbedSoundInst already supports incremental decoding (currently threaded), so there seems no reason not to parse it chunk by chunk. If the chunk is too small, the worst that can happen is that the sound gets choppy while waiting for data to decode, but a value of e.g. 2 << 14 seems a reasonable balance. Most event sounds are smaller than this anyway, so wouldn't require more than one pass.

One effect is that the decoders frequently get incomplete frames, but we hope that they will then signal that they did not consume all the data, and get it again on the next chunk.

Anyway, decoding in chunks makes it play immediately for me, so if I find no adverse side-effects I'll commit it.

Using 0.8.4 and 0.8.5, since the whole sound file is decoded before playback, sound and slides are played fine, but it takes a long time before file is played.

Using 0.8.6, the regression is double, because the ActionScript code that advances slides starts before the event sound has started playing (playback starts after decoding whole sound file), so there is a mismatch between audio and slides.

I guess that fixing the originally reported bug would make possible to report other bugs with Gnash playing this file.

Trunk plays both the sound and the slides for me, but it (a) doesn't load it like the flashplayer does and (b) has a long pause with high CPU activity before starting to play. I wouldn't be surprised if we're doing what's described in the swfdec bug, that is, decoding the whole thing before playback.