After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 347529 - wavparse error
wavparse error
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal blocker
: 0.10.4
Assigned To: Edward Hervey
Edward Hervey
Depends on:
Blocks:
 
 
Reported: 2006-07-14 15:55 UTC by Janos Csikos
Modified: 2006-08-10 14:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
test source (12.07 KB, text/plain)
2006-07-14 15:57 UTC, Janos Csikos
  Details
Test case for the bug (3.81 KB, text/x-python)
2006-07-30 20:07 UTC, Jono Bacon
  Details
Glade file for use with test case (2.75 KB, application/xml)
2006-07-30 20:09 UTC, Jono Bacon
  Details
Send newsegment in the streaming thread. (1.76 KB, patch)
2006-08-09 16:34 UTC, Edward Hervey
none Details | Review

Description Janos Csikos 2006-07-14 15:55:17 UTC
Please describe the problem:
I've had some issues with the wavparse element when used with gnonlin. I modified
the test program, which comes with gnonlin to play it wav-s and it wasnt
success.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Janos Csikos 2006-07-14 15:57:28 UTC
Created attachment 68932 [details]
test source 

it use default the wavparse element, and it use mad with -DUSE_MP3 compile parameter.
Comment 2 Damien Durand 2006-07-15 13:11:34 UTC
Thanks for taking the time to report this bug.
This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug.
Comment 3 Akos Maroy 2006-07-15 14:11:49 UTC
ok, some more detail then:

when trying to build an audio player with gnonlin using the wavparse element, it just doesn't seem to work. wavparse has dinamic pads, and one needs to catch the pad-added event to link it to a next element. but, for some reason the pad-added event never gets fired. the structure of gnlsource looks like this when using wavparse:

bin { filesrc - wavparse audioconvert }

with the src pad of audioconvert ghosted to the src pad of the bin.

doing the same setup, but not inside a gnlsource element works fine:

bin { filesrc - wavparse audioconvert } - alsasink


doing the very same setup within gnlsource with a mad element instead of wavparse (which has fixed pads), it all works fine. (you can get this result if compiling with -DUSE_MP3)

I hope this description is detailed enough
Comment 4 Tim-Philipp Müller 2006-07-17 09:30:42 UTC
The bug has a test case that is supposed to demonstrate the bug, that should be good enough as well => re-opening (haven't actually tried it though).

Comment 5 Jono Bacon 2006-07-30 20:07:13 UTC
I have experienced this bug too, and it quite affects Jokosher. It certainly a problem with gnonlin, as this works fine:

jono@forge:~/pythontests$ gst-launch-0.10 filesrc location="/home/jono/media/audioforjokosher/jonobacon-thelake-short.wav" ! decodebin ! audioconvert ! alsasink

I have attched a script that demonstrated the bug. The script uses gnonlin.
Comment 6 Jono Bacon 2006-07-30 20:07:55 UTC
Created attachment 69921 [details]
Test case for the bug
Comment 7 Jono Bacon 2006-07-30 20:09:23 UTC
Created attachment 69922 [details]
Glade file for use with test case
Comment 8 Edward Hervey 2006-08-09 16:34:32 UTC
Created attachment 70561 [details] [review]
Send newsegment in the streaming thread.

wavparse is sending non-flushing events in gst_wavparse_perform_seek() which is being called by an outside thread. If a pad is blocked downstream, that thread will block.

The attach patch fixes that issue by putting the sending of the newsegment event in the streaming thread.
Comment 9 Jono Bacon 2006-08-09 23:18:41 UTC
I can confirm that the patch fixes the problem.

Although is great for this bug, #341431 is still acting as a showstopper for WAV support in Jokosher.
Comment 10 Thomas Vander Stichele 2006-08-10 14:10:47 UTC
commited