Sat 26 Sep 2015 08:30:18 AM UTC, comment #34:
I get now that what exactly the "_real fun_" means when Gnash's `./configure`
script tried to convince me to install Csound.
But, seriously, the configure script should be more clear on what Csound have
to do with Gnash's build, e.g. for generating sound-related test cases.
(Patch included; see patch #8753)
|
Wed 23 Sep 2015 01:56:09 PM UTC, comment #33:
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.
|
Wed 23 Sep 2015 01:49:42 PM UTC, comment #32:
All pending patches have been pushed, back to automated testing.
|
Sun 20 Sep 2015 07:12:18 AM UTC, comment #31:
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
|
Sat 19 Sep 2015 03:58:48 PM UTC, comment #30:
The attached `pcmplay-11k.zip` contains more resampler test files, including
sounds and build scripts, using 11025 Hz sample rate, in all combination
of `UNCOMPRESSED`/`RAW` (little-endian) format, 16-bit/8-bit depth,
mono and stereo.
(file #34927)
|
Sat 19 Sep 2015 03:55:29 PM UTC, comment #29:
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)
|
Fri 18 Sep 2015 05:50:27 AM UTC, comment #28:
We're counting on you to provide a patch.
You did a wonderful work so far, and there seem to be a lot more to do. It would be a pity for all this work to be ruined in the future so I'd stress out again that sound decoding currently has zero automated tests. If you can provide that it will be extremely rewarding in the long run.
|
Fri 18 Sep 2015 05:19:29 AM UTC, comment #27:
I've tested around Gnash's FFmpeg/libAV-based codec backend, and found problem on many levels:
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
|
Thu 17 Sep 2015 02:26:20 PM UTC, comment #26:
Note (for the record): embeded 8-bit PCM `UNCOMPRESSED` and `RAW` event sound
is encoded in an unsigned 8-bit PCM format.
If you run following commands with `pcmplay-8bit.swf` and `rawpcmplay-8bit.swf`
you will hear the correct siren sound:
But if you changed the `-f U8` part to `-f S8` (signed PCM), you'd hear a hoarse wailing instead.
|
Mon 14 Sep 2015 11:35:51 AM UTC, comment #25:
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
|
Mon 14 Sep 2015 08:44:22 AM UTC, comment #24:
Patches pushed as commits 76b8fa551a4c4849c72318e6fb7bcafb070485db and c16e78cd22f2fb2c656c378399aba0d3956e5254
Any idea on how decoding sound could be automatically tested ?
|
Mon 14 Sep 2015 07:52:36 AM UTC, comment #23:
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
|
Mon 14 Sep 2015 07:37:10 AM UTC, comment #22:
The attached file (`rawpcmplay.zip`) contain test SWF files for raw PCM
event sound in combination of both bit depth 16-bit (little endian) and 8-bit,
both 1 and 2 channels, together with source sound, code, and build scripts.
Testing current Gnash git using `rawpcmplay-8bit.swf` and `rawpcmplay-stereo-8bit.swf`
on both media handler backend yields result similar to `pcmplay-8bit.swf` and `pcmplay-stereo-8bit.swf`:
- FFmpeg/libAV backend:
- `rawpcmplay-8bit.swf`: played with weird wail followed
- `rawpcmplay-stereo-8bit.swf`: aborted, or crashed
- GStreamer backend:
- `rawpcmplay-8bit.swf: played OK
- `rawpcmplay-stereo-8bit.swf`: played with gibberish followed, or crashed
On the other hand, raw little-endian 16-bit PCM (both mono and stereo)
seems to play properly on both FFmpeg and Gstreamer media handler.
Gnash: 0.8.11dev (git f5016cc 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)
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 #34872)
|
Sun 13 Sep 2015 01:48:30 PM UTC, comment #21:
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
|
Sun 13 Sep 2015 01:45:23 PM UTC, comment #20:
The "`libmedia/AudioDecoderSimple.cpp` line 393" phrase in previous post
was misquoted, sorry. The correct line number should be 404:
http://git.savannah.gnu.org/cgit/gnash.git/tree/libmedia/AudioDecoderSimple.cpp?id=f5016cc9399c9ffd3c5d32c67bb28fac285559c6#n404
Mistake aside, the issue (and fix) might similarly apply to 8-bit `RAW` codec too.
But I will try to create test files for confirming it first.
|
Sun 13 Sep 2015 01:17:45 PM UTC, comment #19:
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:
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
|
Sat 12 Sep 2015 05:12:20 PM UTC, comment #18:
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
- GStreamer backend:
- `pcmplay.swf`: played OK
- `pcmplay-stereo.swf`: played OK
- `pcmplay-8bit.swf: played OK
- `pcmplay-stereo-8bit.swf`: played with gibberish followed, or crashed
For audio dumps from 8-bit PCM tests (including log message, and GDB backtrace
when Gnash aborted or crashed), see the previously attached `pcmplay-8bit_gnash0.8.11dev-775c5fe_diagnostic.zip`.
Gnash: 0.8.11dev (git 775c5fe 9-Sep-2015 with `show-sound-decoding-diagnostic.patch`)
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
|
Thu 10 Sep 2015 03:45:40 AM UTC, comment #17:
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)
|
Wed 09 Sep 2015 02:55:50 PM UTC, comment #16:
workaround patch committed. It also made sense to size the chunk as documented by the comment above (2^16) rather than one byte less...
|
Wed 09 Sep 2015 01:51:53 PM UTC, comment #15:
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
|
Wed 09 Sep 2015 09:25:24 AM UTC, comment #14:
Regarding "PCM decoder" mentioned in comment 12:
- With `gnash --media=ffmpeg`, PCM decoding (and sample format conversion) is done through FFmpeg/libAV:
- With `gnash --media=gst`, PCM decoding (and sample format conversion) is done entirely in Gnash:
Gnash: 0.8.11dev (git ba8ab1d 07-Sep-2015)
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)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Tue 08 Sep 2015 10:47:51 AM UTC, comment #13:
Is the PCM decoder a Gnash class or is it internal to gst/ffmpeg ?
|
Tue 08 Sep 2015 10:38:24 AM UTC, comment #12:
From result in previous posts, it seems that both Gnash's media codec
handler backend (FFmpeg and GStreamer-based) have a problem on incremental
decoding of uncompressed PCM audio. The issue is caused by either:
- PCM decoder does not consume source data in a block size that is rounded to frame boundary. Or...
- PCM decoder does not keep the remainder byte(s) for decoding in the next go.
This issue surfaced when the decoder is requested to read in a block that is
not a multiple of frame size, resulting in misalignment, thus nasty screech
are being decoded instead of desired sound in the second decoder call
(and so on).
Fixing the second issue (by keeping the remainder bytes in the decoder for use
in the next try) would make the incremental decoding works even when
the requested chunk size is as small as 1 byte.
|
Tue 08 Sep 2015 10:07:09 AM UTC, comment #11:
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
|
Tue 08 Sep 2015 09:59:00 AM UTC, comment #10:
For stereo cases (`pcmplay-stereo.swf`):
The problem is similar to normal ones: decoder, both FFmpeg and GStreamer,
seemed to consume 65535 bytes which is not rounded to frame boundary.
Symptiom difference (FFmpeg V.S. GStreamer) is that GStreamer one seems to be
more straightforward; as the audio [fits Gnash's internal sample format],
it was passed verbatim without consideration of frame size,
and tripped assertion error.
Side note: I'm not sure if the assertion check [`assert(!(decodedDataSize%2))`
is correct, since Gnash's internal sample format seems to use 4 bytes/frame
not 2 bytes/frame.
For the double screeching (FFmpeg), I figured it was due to size of the audio,
the misalignment started earlier, and covered the area where original
siren sound changes frequency, thus the screech changed into second pattern.
With second chunk ended before the end of sound, third `.decode()` call
resulted in a second misalignment; making the frame partially aligned again
(sample is aligned but flipped channel), this makes the final bits of
siren sounds apparently normal again.
Playing `pcmplay-lr.swf` (from the attached `pcmplay-lr.zip`) under Gnash
using FFmpeg backend will show the symptom of flipped channel
after the second screech.
(file #34835)
|
Tue 08 Sep 2015 09:49:56 AM UTC, comment #9:
From the attached `pcmplay_gnash0.8.11dev-dc51f53_diagnostic.zip`.
This is an exerpt from output on playing `pcmplay.swf` using FFmpeg backend:
(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:
(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).
|
Mon 07 Sep 2015 07:37:14 PM UTC, comment #8:
bug #25456 was reported as being a regression, btw
|
Mon 07 Sep 2015 12:22:32 PM UTC, comment #7:
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)
|
Fri 04 Sep 2015 08:24:04 AM UTC, comment #6:
I've re-tested the regression on a new system where modern FFmpeg/libAV is available.
I think it's important to note that Gnash's FFmpeg and GStreamer backend
are both affected by this issue, and traced back to the same commit.
Though the symptom of pcmplay-stereo case is a bit different between FFmpeg
and GStreamer (double screech V.S. assertion failure).
These are summary of result on Gnash playing two attached test files:
- Pre-regression commit (77966b2), FFmpeg/libAV backend:
- pcmplay.swf: played OK
- pcmplay-stereo.swf: played OK
- Pre-regression commit (77966b2), GStreamer backend:
- pcmplay.swf: played OK
- pcmplay-stereo.swf: played OK
- Regression commit (7a53cb3), FFmpeg/libAV backend:
- pcmplay.swf: played with screech
- pcmplay-stereo.swf: played with double screech
- Regression commit (7a53cb3), GStreamer backend:
- pcmplay.swf: played with screech
- pcmplay-stereo.swf: assertion failed
Screech sounds are apprently the same as ones in each corresponding videos attached earlier
(`pcmplay_gnash0.8.11dev-6b269f9.ogv` for FFmpeg-mono and GStreamer-mono,
`pcmplay-stereo_gnash0.8.11dev-f341372.ffmpeg.ogv` for FFmpeg-stereo)
Assertion failure message in GStreamer-stereo case is still the same as comment 1
(GDB backtrace using f341372 is also available inside the `pcmplay-stereo.zip` attached earlier)
Gnash: 0.8.11dev (git 77966b2), 0.8.11dev (git 7a53cb3)
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
|
Thu 03 Sep 2015 09:51:40 PM UTC, comment #5:
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.
|
Wed 02 Sep 2015 08:43:53 AM UTC, comment #4:
I the previous post I said "pcmsound.swf" and "pcmsound-stereo.swf",
I actually meant to say "pcmplay.swf" and "pcmplay-stereo.swf".
They were mistyped, sorry.
|
Wed 02 Sep 2015 08:39:50 AM UTC, comment #3:
Git bisect test (dc51f53 bad, 0.8.10 good) using `pcmsound.swf` and `pcmsound-stereo.swf` revealed that:
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:
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
|
Wed 02 Sep 2015 08:36:08 AM UTC, comment #2:
I tested on an older system and found that Gnash 0.8.10 played both
`pcmplay.swf` and `pcmplay-stereo.swf` smoothly, without any screech.
Gnash: 0.8.10 (source)
SDL: libsdl1.2debian 1.2.14-6.1 (debian)
FFmpeg: libavcodec52 4:0.5.10-1 (debian), libavformat52 4:0.5.10-1 (debian), libavutil49 4:0.5.10-1 (debian)
GStreamer: libgstreamer0.10-0 0.10.30-1 (debian)
System: Debian GNU/Linux 6.0 Squeeze i386
|
Thu 27 Aug 2015 07:59:33 AM UTC, comment #1:
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).
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)
|
Sat 08 Aug 2015 04:10:32 PM UTC, original submission:
I have created a simple flash file from SWFMill/MTASC (Flash 8) which have
a single PCM sound in the library, and use `Sound.start()` in ActionScript
to play it.
When running the file on Gnash, its sound seems to play smoothly at first.
But as soon as the sound ended, Gnash emitted a short loud screech.
The attached `pcmplay_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_gnash0.8.11dev-6b269f9.ogv` is a video result from Gnash:
You'll see that as soon as siren sound ended, loud screech followed.
This symptom occurs with both FFmpeg and GStreamer media handler.
Screech is also captured when `--audio-dump` is used.
Also, this issue didn't apply to MP3-compressed sound object.
Test flash file, sound, source code and build script are attached as `pcmplay.zip`.
Siren sound embeded is PCM 44100Hz 16-bit Mono, with the length of 1.0 sec
(44100 samples total).
Gnash: 0.8.11dev (git 6b269f9 24-May-2015)
Adobe Flash Player: 11.2 r202 (11.2.202.491) standalone
System: Debian GNU/Linux 7.0 Wheezy i386
|