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 555307 - Need to push latency event into the pipeline
Need to push latency event into the pipeline
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.22
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-10-06 22:26 UTC by Olivier Crête
Modified: 2008-10-16 07:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Olivier Crête 2008-10-06 22:26:00 UTC
I've written an element that wraps the libspeexdsp voice preprocessing functions [1]. One the the things that it does is acoustic echo cancellation. 

To do echo cancellation, I need to what exactly was being played out when something else was recorded, that requires knowing the current latency.

In gst_base_sink_send_event(), it does not forward the latency event. I propose just removing the "forward = FALSE" line. Also, I don't think the comment in there is still relevant.

[1] http://git.collabora.co.uk/?p=user/tester/gst-plugins-farsight-tester.git;a=tree;f=ext/speexdsp;h=afb445a9471dba46635572881fe1aec43b14ce91;hb=refs/heads/speexdsp
Comment 1 Wim Taymans 2008-10-07 08:39:18 UTC
I always thought that we needed to hook the echo cancelation between the audio sink and source ringbuffers to get this functionality reliably right.

Simply forwarding the latency is probably not enough, I'm not sure.
Comment 2 Olivier Crête 2008-10-07 13:53:41 UTC
Is there any latency introduced by the sink thats not reported by the latency query? Just forwarding the latency event seems to work for me.
Comment 3 Wim Taymans 2008-10-08 11:01:21 UTC
the latency reported by the sink to the pipelie is the ultimate latency, it should include all latencies.

I guess it's ok to send the total latency downstream. Elements can't really use it to do anything clock related because they can't know how much downstream latency there is but then again, elements only currently use downstream latency + their own latency, which makes more sense anyway.
Comment 4 Wim Taymans 2008-10-08 12:36:21 UTC
unfortunatly it seems to cause some trouble with plugins that don't forward the event properly.
Comment 5 Wim Taymans 2008-10-08 14:21:23 UTC
Ok, commited. Let's find the offending elements like this.

        * libs/gst/base/gstbasesink.c: (gst_base_sink_send_event):
        Forward LATENCY events upstreams so that elements know about the total
        pipeline latency. Fixes #555307.
Comment 6 Olivier Crête 2008-10-09 19:04:05 UTC
Maybe basesink should override the retval from the gst_pad_push_event() in the case of the latency event and always return TRUE, since its only an "informational" event for the downstream elements...

Otherwise, this kind of strange, but previously valid pipeline "fakesink async=false sync=false fakesrc ! fakesink" produces a warning.