bugGnash - The GNU Flash player - Bugs: bug #24417, Sound problems with gst (slow...

 
 

bug #24417: Sound problems with gst (slow decoding, pseudo hang)

Submitted by:  Benjamin Wolsey <bwy>
Submitted on:  Tue 30 Sep 2008 05:57:33 PM UTC  
 
Category: sound-gstSeverity: 4 - Important
Release: trunkStatus: Wont Fix
Privacy: PublicAssigned to: Bastiaan Jacques <bjacques>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Thu 23 Oct 2008 11:48:00 AM UTC, comment #16:

Another option I just thought of: instead of using Gstreamer for audio resampling, we can use Util::convert_raw_data, if neither speexresample nor ffaudioresample are available. I suspect that code would be faster, although it admits it is "crude", so I don't expect very good quality.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Fri 10 Oct 2008 01:07:21 PM UTC, comment #15:

Another option here is to run missing-plugins for {speex,ffaudio}resample. But some distributions don't ship either, so we need the ability to give the user a "stop nagging me" option, or otherwise Gnash will (indirectly) pop up the codec dialogue which doesn't have a package for the requested plugin.

That said, this is fixed insofar as it can be fixed for the release.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Tue 07 Oct 2008 06:35:12 AM UTC, comment #14:

the libai-layer2-20-sound.swf is also much much better here.

Sandro Santilli <strk>
Project Member
Mon 06 Oct 2008 07:00:30 PM UTC, comment #13:

I've tested on this laptop (Mandriva 2008). It's much better than it was, but still has small gaps. It must be using the speex decoder, and hopefully ffmpegaudioresample is still quicker.

Perhaps a configure warning would be useful for gstreamer-ffmpeg, because audioresampler's speed is really not funny.

I see swfdec does the same, so there are no wizard answers from that direction either...

Benjamin Wolsey <bwy>
Project Member
Mon 06 Oct 2008 05:58:39 PM UTC, comment #12:

The issue is not actually decoding; it's resampling. It's very slow (as you've seen). I've committed a partial fix which will try to use ffaudioresample, or speexresample, if either are available. If they're not an error message is printed.

I'm not sure if there's a better way to handle this situation.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Mon 06 Oct 2008 07:38:48 AM UTC, comment #11:

The same pseudo-hang happens with this:
libai-layer2-20-sound.swf
md5: c0f53d2a7412573c79f648ae00e4bf21
attached in a message on gnash-dev by Richard Tseng
on Sat, 3 May 2008 19:48:33

I took times. It takes 2 seconds with ffmpeg and 60 with gst,
the latter using 100% CPU during those 60 seconds. Tested by opening the right-click menu and massaging items...

I reported this in bug #23203, but seems more topic here
so I'll close the other.

Sandro Santilli <strk>
Project Member
Mon 06 Oct 2008 06:47:18 AM UTC, comment #10:

Yes, you're right, after about 3 minutes(!) it carries on. I guess it's the same for the other (weebls-stuff) SWF, only it has much more audio to decode and takes correspondingly longer.

Benjamin Wolsey <bwy>
Project Member
Sun 05 Oct 2008 10:21:51 PM UTC, comment #9:

Nevermind that request. I managed to reproduce the stacktrace coming from sdl_audio_callback. Can you confirm that if you leave the "deadlocked" window playing four-second-fury sitting for a while (~30 seconds in my case), playback continues as normal?

It looks like gstreamer is simply taking a very long time to decode ~1MB of audio.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Sun 05 Oct 2008 09:55:51 PM UTC, comment #8:

Can you provide some backtraces from all threads when the deadlock has happened?

I've been playing with four-second-fury, and in some runs I see a ~30 second freeze from MediaParser::clearBuffers() / ADPCMDecoder::adpcm_expand(), actually pointing to a data race involving print output... But the stacktrace does not look very clean.

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Sun 05 Oct 2008 09:00:48 PM UTC, comment #7:

I can reproduce this on a machine running Mandriva 2008.1 and one running 2009.0 rc2.

Having spent the evening watching locks in gdb, I can confirm that that the thread is locked in

SDL_sound_handler::sdl_audio_callback (void udata, Uint8 stream, int buffer_length_in)

and is still locked when play_sound() is called.

For confirmation, commenting out the lock in sdl_audio_callback prevents the hang (but obviously makes a mess of the sound...)

Ffmpeg has no problems with this, so I think it is a gst bug.

Benjamin Wolsey <bwy>
Project Member
Sun 05 Oct 2008 12:37:50 PM UTC, comment #6:

Hang is still there on the weebls-stuff movie.

Four-second-fury seems to stutter less to begin with, but also hangs in sound_handler_sdl::load_sound() once you start playing. There are also occasional gaps in the audio with high CPU load (more locking probelms?). It's not a slow system.

Benjamin Wolsey <bwy>
Project Member
Sun 05 Oct 2008 11:54:40 AM UTC, comment #5:

The stuttering issue should now be fixed in trunk. Could you try to see if the hang still occurs?

A weakness inherent to the current sound handler design is that decoding will happen on-the-fly, which is likely to cause small delays unless you have a fast system. That said, they should not be "show stoppers".

Bastiaan Jacques <bjacques>
Project MemberIn charge of this item.
Wed 01 Oct 2008 07:43:01 AM UTC, comment #4:

The hang is waiting for the lock in sdl_sound_handler::play_sound()

Benjamin Wolsey <bwy>
Project Member
Tue 30 Sep 2008 07:04:20 PM UTC, comment #3:

Ffmpeg works fine for me for both.

Benjamin Wolsey <bwy>
Project Member
Tue 30 Sep 2008 06:47:36 PM UTC, comment #2:

Have you tried ffmpeg ? (four-second-fury isn't very clean for me with ffmpeg Lavc0d.51.11.0)

Sandro Santilli <strk>
Project Member
Tue 30 Sep 2008 05:57:55 PM UTC, comment #1:

They work with -r1.

Benjamin Wolsey <bwy>
Project Member
Tue 30 Sep 2008 05:57:33 PM UTC, original submission:

These are all with embedded sound.

The SWF from bug #16980 stutters a lot and doesn't play properly
(http://www.koreus.com/media/four-second-fury.html)

The SWF http://www.weebls-stuff.com/flash/8594trev3.swf (bug #23916) (and all other weebls-stuff SWFs I've tried) plays no sound and hangs. Gnash won't exit either.

Benjamin Wolsey <bwy>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bjacques (Posted a comment)
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by bwy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 20 Feb 2011 08:00:28 PM UTCbjacquesStatusConfirmed=>Wont Fix
      Open/ClosedOpen=>Closed
    Thu 23 Oct 2008 11:48:00 AM UTCbjacquesStatusPostponed=>Confirmed
    Fri 10 Oct 2008 01:07:21 PM UTCbjacquesStatusFixed=>Postponed
    Fri 10 Oct 2008 01:07:20 PM UTCbjacquesSeverity5 - Blocker=>4 - Important
    Mon 06 Oct 2008 05:58:38 PM UTCbjacquesStatusConfirmed=>Fixed
    Mon 06 Oct 2008 07:38:48 AM UTCstrkSummarySound problems with gst.=>Sound problems with gst (slow decoding, pseudo hang)
    Sun 05 Oct 2008 09:00:48 PM UTCbwyStatusReady For Test=>Confirmed
    Sun 05 Oct 2008 11:54:40 AM UTCbjacquesStatusNone=>Ready For Test

    Back to the top


    Powered by Savane 3.1-cleanup1