If you look under testsuite/sound there's a "brokenchord.wav" file which although distributed can be generated by having "csound" installed (see Makefile for the rule).

It'd be interesting to see if we can get csound to output all the type of sounds we need for testing.

Patches included for FFmpeg 8-bit PCM wailing and and crashing case:
see patch #8747.

After applied patch 1-5, all test files provided so far in this bug entry
seems to play properly with `gnash --media=ffmpeg`. They were tested
with `gnash --media=gst` too; no problem found.

I also done few tests for side effect of the fix on other codecs,
and found none so far. (But the test is performed on only one version of libAV,
and covered only few variety of codec parameters)

Gnash: 0.8.11dev (patched against git 516a6ca 15-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

The attached `pcmplay-22k.zip` contains additional resampler test files,
sounds, and build scripts, using 22050 Hz sample rate, in all combination
of `UNCOMPRESSED`/`RAW` (little-endian) format, 16-bit/8-bit depth,
mono and stereo.

(file #34926)

I've tested around Gnash's FFmpeg/libAV-based codec backend, and found problem on many levels:

• Gnash's FFmpeg-based sample format converter uses a hard coded assumption that input sample format is 16-bit signed PCM when `swresample.h` and `avresample.h` are both unavailable.
• Gnash's FFmpeg-based sample format converter wouldn't attempt to convert 8-bit PCM input sound when `swresample.h` and `avresample.h` are both unavailable.
• Gnash's FFmpeg-based codec handler uses a wrong codec ID for 8-bit embeded PCM sound (Gnash mistakenly uses signed PCM, but it really is unsigned PCM).
• Gnash's FFmpeg-based codec handler divided sample rate with 2 if the source audio is 8-bit PCM for an unobvious reason. As the SWF parser seems to give a correct sample rate (e.g. 44100 Hz in `pcmplay-8bit.swf` test), I think the divisor was put there to work around other problems listed here.
• Gnash's FFmpeg-based audio frame decoder uses an incorrect calculation for resampling buffer size. (`resampleFactor` should account only sample rate change, as channels number change is multiplied in later)
• Gnash's FFmpeg-based audio frame decoder uses a hard-coded assumption that the decoded audio uses 2 bytes/samples when calculating total samples to convert. (Which produces an incorrect number when the decoded audio is 8-bit PCM, as it uses 1 byte/sample)

These problems seems to be very closely related that all of them would have
to be fixed at the same instant to get the correct behavior.

Gnash: 0.8.11dev (git 516a6ca 15-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Please note that Gnash with FFmpeg/libAV backend is still not playing 8-bit PCM (and 8-bit raw PCM) properly.
(Submitted patches fixes only GStreamer backend)

These are summary of result on current Gnash playing test files:

• FFmpeg/libAV backend:
  • `pcmplay.swf`: played OK
  • `pcmplay-stereo.swf`: played OK
  • `pcmplay-8bit.swf: played with weird wail followed
  • `pcmplay-stereo-8bit.swf`: aborted, or crashed
  • `rawpcmplayle.swf`: played OK
  • `rawpcmplayle-stereo.swf`: played OK
  • `rawpcmplay-8bit.swf`: played with weird wail followed
  • `rawpcmplay-stereo-8bit.swf`: aborted, or crashed
• GStreamer backend:
  • `pcmplay.swf`: played OK
  • `pcmplay-stereo.swf`: played OK
  • `pcmplay-8bit.swf: played OK
  • `pcmplay-stereo-8bit.swf`: played OK
  • `rawpcmplayle.swf`: played OK
  • `rawpcmplayle-stereo.swf`: played OK
  • `rawpcmplay-8bit.swf`: played OK
  • `rawpcmplay-stereo-8bit.swf`: played OK

For GDB backtraces on FFmpeg 8-bit stereo (uncompressed PCM) case, see the
previously attached `pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`.

I think that crashes/aborts on uncompressed 8-bit stereo sound and
raw 8-bit stereo sound are the same, as they were handled by the same decoder (AV_CODEC_ID_PCM_S8).

For the FFmpeg wailing (8-bit mono, both uncompressed and raw), I'm not sure of the cause.
(The audio dump from uncompressed PCM case is in `pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`)

Gnash: 0.8.11dev (git e4c2ac8 14-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Patch included for raw 8-bit stereo GStreamer case: patch #8738 comment 2.

After applied patch 1-2 from patch #8738, Gnash (using `--media=gst`) seems
to play both `pcmplay-stereo-8bit.swf` and `rawpcmplay-stereo-8bit.swf` properly.

FFmpeg/libAV cases on 8-bit uncompressed PCM and raw PCM (both mono wailing
and stereo crashing), are remaining to be fixed.

Gnash: 0.8.11dev (patched against git f5016cc 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Patch included for 8-bit stereo GStreamer case: see patch #8738.

After applied this patch, Gnash (using `--media=gst`) played
`pcmplay-stereo-8bit.swf` properly.

FFmpeg/libAV cases (both 8-bit mono wailing and 8-bit stereo crashing),
and 8-bit `RAW` PCM codec are remaining to be investigated.

Gnash: 0.8.11dev (patched against git f5016cc 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

I have observed around `AudioDecoderSimple` for bits relating to GStreamer
`pcmplay-stereo-8bit.swf` case, which have normal sound at first, then
followed by either gibberish or crash. Excerpt from diagnostic output:

DEBUG: AudioDecoderSimple: initialized flash codec 3 (Uncompressed)
DEBUG:   decoding 65536 bytes (offset 0, remaining 88200, total 88200)
DEBUG:   decoded to 262144 bytes, used 65536 bytes from source
DEBUG:   decoding 22664 bytes (offset 65536, remaining 22664, total 88200)
DEBUG:   decoded to 90656 bytes, used 22664 bytes from source

An anomaly could be seen in the first "decoded..." line: diagnostic code
reported that 65536 bytes audio get expanded to 262144 bytes, which was
four times of original.

In this case, 2 byte/frame simply got converted to 4 byte/frame should expand
only for two times, not four times.

This could be traced to `libmedia/AudioDecoderSimple.cpp` line 393
The code errneously set output size to four times of input size if the sound
is stereo, even when itself is responsible only for 8-bit to 16-bit conversion,
which always multiplies two. (Note: stereo expansion, when applicable,
is done in later stage and will re-adjust the buffer size again automatically)

When this happens, after outputting the normal sound, SDL output stage tries
to read beyond the audio buffer (due to erroneous buffer size),
leading to gibberish output (or crash).

Gnash: 0.8.11dev (git f5016cc 9-Sep-2015 with `show-sound-decoding-diagnostic.patch`)
SDL: libsdl1.2debian 1.2.15-5 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

There is an interesting problem on Gnash's 8-bit PCM support.
See the attached `pcmplay-8bit.zip` for test files (mono and stereo).

Note: This issue predates the introduction of workaround patch (b7dbb23).
From my tests and observation, the patch didn't change Gnash's behavior
on these 8-bit PCM cases in significant way.

After applied the diagnostic patch (`show-sound-decoding-diagnostic.patch`),
I have tested current Gnash with both FFmpeg and GStreamer backend on both
`pcmplay-8bit.swf` and `pcmplay-stereo-8bit.swf`. Result logs
(verbosity 2 + action error log), audio dumps, and GDB backtraces
(when applicable) from each cases are attached as
`pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`.

Note #1: in `pcmplay-stereo-8bit.swf` case, backtrace and audio dumps are
captured multiple times per media handler. These documents each different style
that Gnash crashed or abort()'d on playing the test file.

Note #2: audio dump from testing `pcmplay-stereo-8bit.swf` on Gnash with
GStreamer backend is fixed using AVconv.

Gnash: 0.8.11dev (patched against git 775c5fe 9-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34845)

Workaround included: patch #8736

This patch (hack) does not address the issue itself, but rather
works around it by always requesting the decoder to read in block size
that is a multiple of PCM frame size (both mono and stereo).

Which this patch, Gnash (both FFmpeg and GStreamer backend) seems to play
both `pcmplay.swf` and `pcmplay-stereo.swf` properly.

Underlying issue of frame boundary rounding (or why the decoder didn't
keep the remainder bytes for the next decoding round) should be fixed
in the each respective backend (both GStreamer and FFmpeg).

This patch should not affect other codec if their decoder do not have
framing problem similar to ones described in comment 12.


Gnash: 0.8.11dev (patched against git c969f9d 8-Sep-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Is the PCM decoder a Gnash class or is it internal to gst/ffmpeg ?

Note: assertion check mentioned in previous post is located here (original markup was messed up a bit):
http://git.savannah.gnu.org/cgit/gnash.git/tree/libsound/EmbedSoundInst.cpp?id=ba8ab1d9757bef44ab9be979072337a9e0fe463e#n118

From the attached `pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip`.

This is an exerpt from output on playing `pcmplay.swf` using FFmpeg backend:

DEBUG: AudioDecoderFfmpeg: initialized FFmpeg codec 65536 (pcm_s16le) for flash codec 3 (Uncompressed)
DEBUG:   decoding 65535 bytes (offset 0, remaining 88200, total 88200)
DEBUG:   decoded to 131028 bytes, used 65535 bytes from source
DEBUG:   decoding 22665 bytes (offset 65535, remaining 22665, total 88200)
DEBUG:   decoded to 45328 bytes, used 22665 bytes from source

(The second set of `decoding ... decoded ...` output is emitted the same time
as screech sound)

From `used 65535 bytes from source` part, it shown that the underlying decoder
consumed audio data in a block that's not aligned to frame boundary.
(PCM 16-bit Mono has frame size of 2 bytes) This has potential of messing up
the subsequent read; which is evident as the second `.decode()` call was
occured at the same moment that screech is audible.

This is an exerpt from output on playing `pcmplay.swf` using GStreamer backend:

DEBUG: AudioDecoderSimple: initialized flash codec 3 (Uncompressed)
DEBUG:   decoding 65535 bytes (offset 0, remaining 88200, total 88200)
DEBUG:   decoded to 131068 bytes, used 65535 bytes from source
DEBUG:   decoding 22665 bytes (offset 65535, remaining 22665, total 88200)
DEBUG:   decoded to 45328 bytes, used 22665 bytes from source

(The second set of `decoding ... decoded ...` output is emitted the same time
as screech sound)

Problem is the same as FFmpeg (`used 65535 bytes from source`), only
difference are decoded sizes of data; GStreamer backend seems to be
more accurate on this; there is 65534 bytes worth of complete frames
on first read, which output data is correctly shown as 131068 bytes.

Note (for the record): As far as I know, Gnash's sound decoding process always
convert sample format to PCM 44100 Hz 16-bit stereo (4-byte/frame).

I have made a dummy patch for showing some diagnostic information on
`AudioDecoder.decode()`, see the attached `show-sound-decoding-diagnostic.patch`.

After applied the patch, I have tested Gnash with both FFmpeg and GStreamer
backend on both `pcmplay.swf` and `pcmplay-stereo.swf`. Result logs
(verbosity 2 + action error log) and audio dumps (if applicable) from
each cases are attached as `pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip`.

Note: audio dump from `gnash --audio-dump` might not be read properly in
some sound editor/player. This issue was reported separately as bug #45887.

(Audio dumps attached above are already fixed using AVconv,
so they could be opened directly in an editor like Audacity)

Gnash: 0.8.11dev (git dc51f53 28-Aug-2015)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian), libav-tools 6:0.8.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34825)

It sounds like AudioDecoderGst is not allowed to do incremental decoding ? I've to admit I mostly focused on FFMPEG media handler as GST was left behind. Maybe Bastiaan can shed a light on the matter.

Git bisect test (dc51f53 bad, 0.8.10 good) using `pcmsound.swf` and `pcmsound-stereo.swf` revealed that:

7a53cb38d4b3f8a8f6160a40e2912133663c1ab3 is the first bad commit
commit 7a53cb38d4b3f8a8f6160a40e2912133663c1ab3
Author: Sandro Santilli <strk@keybit.net>
Date:   Sun Nov 3 19:49:28 2013 +0100

        Decode embedded sound in chunks of 65535 bytes

        Fixes latency in lessig-freeculture.swf:
        https://savannah.gnu.org/bugs/?25456

        Confirms AudioDecoder is already allowed to do incremental decoding:
        https://savannah.gnu.org/bugs/index.php?24638

:040000 040000 b4f35f74ac4a1974de3dd731ba1dbb3d3a540552 22c9c9db76729b744a13b6ccf85265b226380894 M        libsound

In this commit, using `gnash --media=gst pcmsound.swf` resulted in screech
after siren sound. With `gnash --media=gst pcmsound-stereo.swf`, it ended
with an assertion error just like in comment 1:

92 SECURITY: Checking security of URL 'file:///home/window/Desktop/pcmplay/pcmplay-stereo.swf'
92 SECURITY: Load of file /home/window/Desktop/pcmplay/pcmplay-stereo.swf granted (under local sandbox /home/window/Desktop/pcmplay/)
106 SECURITY: Extensions disabled
108 ACTIONSCRIPT ERROR: reference to non-existent variable 'PCMPlayStereo'
gtk-gnash: EmbedSoundInst.cpp:118: virtual void gnash::sound::EmbedSoundInst::decodeNextBlock(): Assertion `!(decodedDataSize%2)' failed.
Aborted

In a commit before the regression (77966b2), both `pcmsound.swf` and
`pcmsound-stereo.swf` played correctly.

Note: `--media=ffmpeg` was not tested due to version requirement.

SDL: libsdl1.2debian 1.2.14-6.1 (debian)
GStreamer: libgstreamer0.10-0 0.10.30-1 (debian)
CSound: libcsound64-5.2 1:5.12.1~dfsg-5 (debian)
System: Debian GNU/Linux 6.0 Squeeze i386

I have tested more by using the same sound but in stereo instead of mono,
the symptom got interesting.

The attached `pcmplay-stereo_fp11.2.202.491.ogv` is a video result from Adobe Flash:
You'll see that siren sound played and stopped normally.

The attached `pcmplay-stereo_gnash0.8.11dev-f341372.ffmpeg.ogv` is a video
result from Gnash using FFmpeg/libAV media handler:
You'd see that there're now two screech, emitted in the middle
of siren sound instead of at the end.

On the other hand, with Gnash using GStreamer media handler,
Gnash window was shown in a blink before it terminated with an assertion error
(no sound was audible).

3623:1] 354 ACTIONSCRIPT ERROR: reference to non-existent variable 'PCMPlayStereo'
3623:1] 355 DEBUG: Loading native class Sound
3623:1] 355 DEBUG: Sound.start: secOff:0 loops:0
3623:1] 371 DEBUG: AudioDecoderSimple: initialized flash codec 3 (Uncompressed)
gtk-gnash: EmbedSoundInst.cpp:118: virtual void gnash::sound::EmbedSoundInst::decodeNextBlock(): Assertion `!(decodedDataSize%2)' failed.

Full Gnash logs of both case (verbosity=2 + action error log), full GDB
backtrace output of GStreamer case, test source code, sound, and build script
are attached (pcmplay-stereo.zip).

Gnash: 0.8.11dev (git f341372 25-Aug-2015)
Adobe Flash Player: 11.2 r202 (11.2.202.491) standalone
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.36-1.2 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

(file #34753)