Created attachment 62911 [details] [review]
Patch for wavparse that contains streaming support

Please feel free to review and comment the patch.

Tommi, can you give an example gst-launch line to test the streaming support?

Here is one example:
gst-launch-0.10 gnomevfssrc location=http://www.moviewavs.com/0058493028/WAVS/Movies/2001/2001_theme.wav ! gstwavparse ! osssink

Stefan: you could also just add a 'queue' after filesrc or gnomevfssrc, that will make wavparse operate chain-based as well.

patch seems fine.

One comment though, this :
+ * Copyright (C) <2006> Nokia Corporation.

It would be more productive to put your actual name and email adress (possible your nokia.com one) instead of just the company hiring you. Like:
+ * Copyright (C) <2006> Tommi Myohanen <ext-tommi.myohanen@nokia.com>

It's still puts your company there, but most importantly you, the person who wrote that code and to which we can ask questions if bugs/issues about that file are seen later on.

there is still a problem with the streaming behaviour: after the first _chain() call it switches back to _loop() - huh?:

$ gdb --args gst-launch-0.10 filesrc location=/home/ensonic/temp/gsr-record-Untitled-7547.g02Kwn.wav ! queue ! wavparse ! audioconvert ! alsasink

(gdb) break gst_wavparse_stream_data
Function "gst_wavparse_stream_data" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gst_wavparse_stream_data) pending.
(gdb) run
Starting program: /usr/bin/gst-launch-0.10 filesrc location=/home/ensonic/temp/gsr-record-Untitled-7547.g02Kwn.wav \! queue \! wavparse \! audioconvert \! alsasink

Breakpoint 2, gst_wavparse_stream_data (wav=0xb71ec1dc) at gstwavparse.c:1335
1335    {
(gdb) bt

+ Trace 67868

Created attachment 64350 [details] [review]
Patch for wavparse that contains streaming support

previous patch was sending events on unallocated pad
TODO: figure out why push mode falls back to pull mode after first buffer

Minor nitpick:

+  if (gst_pad_is_linked (wav->srcpad)) {
+    if ((res = gst_pad_push (wav->srcpad, buf)) != GST_FLOW_OK)
+      goto push_error;
+  } else {
+    gst_buffer_unref (buf);
+    goto not_linked;
+  }

that's unnecessary, if not racy. There's no need to check if the pad is linked in advance, GST_FLOW_NOT_LINKED should just be handled like any other non-FLOW_OK flow value.

Created attachment 64452 [details] [review]
Patch for wavparse that contains streaming support

now streaming works