GNOME Bugzilla – Bug 653601
audiodelay: new element in audiofx providing an audio delay line
Last modified: 2014-02-27 21:08:26 UTC
Created attachment 190894 [details] proposed patch for gst-plugins-good This patch proposes adding a new element to audiofx. The new element is called "audiodelay." It delays an audio signal by a specified number of samples by emitting a gap buffer.
Could we call this audiogap or something like it. A delay is usually a delays line like in audioecho. It would also e great to mention in the doc-blob when one would eg. want to use it. Regarding the patch, I think it relies on the BUFFER_OFFSET fields beeing set in the received buffers. guint64 len = GST_BUFFER_OFFSET_END (buf) - GST_BUFFER_OFFSET (buf);
There is also bug 641024, that talks about a delay element.
This element is a little different from the one in bug 641024, because the incoming and outgoing streams are intended to conform to the same segment -- hence, the initial gap in addition to the timestamp remapping. This is intended to make it possible to send one stream and its delayed counterpart into an adder. I could add a boolean property (true by default) to turn on or off the initial gap buffer, thus optionally providing the behavior of bug 641024. I agree that this is more properly thought of as a timestamp shift; the "delay line" part would really be any queue that followed this element. I still prefer the name "audiodelay" because in a pipeline where this element is used it will have the effect of causing the non-silence part of the signal to be played back at a later time. How about "audiotimestampshift" or "audiotimestampoffset" as alternative names?.
(In reply to comment #1) > Could we call this audiogap or something like it. A delay is usually a delays > line like in audioecho. It would also e great to mention in the doc-blob when > one would eg. want to use it. > > Regarding the patch, I think it relies on the BUFFER_OFFSET fields beeing set > in the received buffers. > guint64 len = GST_BUFFER_OFFSET_END (buf) - GST_BUFFER_OFFSET (buf); Oops. I'll fix that.
One reason I was suggestion a different name is that I would suggest it with an audio-effect and that would have modulatable delaytime and feedback ratio and ... I assume your elements is needed to do av-sync correction. I'd say it would be good to have a av-sync-correction element that works for both audio and video.
(In reply to comment #5) > One reason I was suggestion a different name is that I would suggest it with an > audio-effect and that would have modulatable delaytime and feedback ratio and I see. You have something like <http://en.wikipedia.org/wiki/File:Ibanez_de7.jpg> in mind. > I assume your elements is needed to do av-sync correction. I'd say it would be > good to have a av-sync-correction element that works for both audio and video. My application actually involves literally a sample delay, what would be a z^-N in a signal flow diagram or a transfer function. I have to send a signal through an audiofirfilter, then delay it, then add it to another signal. This saves having to pad the FIR filter coefficients with a whole bunch of zeros.
Created attachment 191120 [details] [review] proposed patch for gst-plugins-good Adds information about use cases to doc-blob. Also, no longer relies on the sink pad's signal having valid offsets.
So its the same as the existing audioecho effect with intensity=100% and feedback=0%, but a lot more efficient. Regarding your doc-blob change, please don't suggest the element to be used for creating an echo effect. One can only achieve that by mixing the original signal in and should just use audioecho then directly. I don't know what other think, but I would like this not to be classified as an effect. Just imagine someone doing a gstreamer audio effect rack. If one plugs this elements as an insert effect one would not really hear a differences before and after. Aren't the audiofilters properly answering the LATENCY query?
(In reply to comment #8) > So its the same as the existing audioecho effect with intensity=100% and > feedback=0%, but a lot more efficient. I don't think this proposed element is the same. It is supposed to output a delayed copy of the input. When intensity=100% and feedback=0%, doesn't audioecho output the sum of the input and a delayed copy of itself? > Regarding your doc-blob change, please don't suggest the element to be used for > creating an echo effect. One can only achieve that by mixing the original > signal in and should just use audioecho then directly. Fixed in new patch. > I don't know what other think, but I would like this not to be classified as an > effect. Just imagine someone doing a gstreamer audio effect rack. If one plugs > this elements as an insert effect one would not really hear a differences > before and after. Should I put this element in a standalone plugin of the same name?
Created attachment 191134 [details] [review] proposed patch for gst-plugins-good doc-blob no longer mentions echo effect
(In reply to comment #9) > (In reply to comment #8) > > So its the same as the existing audioecho effect with intensity=100% and > > feedback=0%, but a lot more efficient. > > I don't think this proposed element is the same. It is supposed to output a > delayed copy of the input. > > When intensity=100% and feedback=0%, doesn't audioecho output the sum of the > input and a delayed copy of itself? Right, need to check how it works in audioecho. In the audiodelay element I have in gst-buzztard I have a drywet control: beats-per-minute : the number of beats per minute the top level pipeline uses flags: readable, writable Unsigned Long. Range: 1 - 18446744073709551615 Default: 120 Current: 120 drywet : Intensity of effect (0 none -> 100 full) flags: readable, writable, controllable Unsigned Integer. Range: 0 - 100 Default: 50 Current: 50 delaytime : Time difference between two echos as milliseconds flags: readable, writable, controllable Unsigned Integer. Range: 1 - 1000 Default: 100 Current: 100 feedback : Echo feedback in percent flags: readable, writable, controllable Unsigned Integer. Range: 0 - 99 Default: 50 Current: 50 > > > Regarding your doc-blob change, please don't suggest the element to be used for > > creating an echo effect. One can only achieve that by mixing the original > > signal in and should just use audioecho then directly. > > Fixed in new patch. > > > I don't know what other think, but I would like this not to be classified as an > > effect. Just imagine someone doing a gstreamer audio effect rack. If one plugs > > this elements as an insert effect one would not really hear a differences > > before and after. > > Should I put this element in a standalone plugin of the same name? Maybe, at least change the classification. "Filter/Effect/Audio" hints that it is an effect. I would like to see what Thiago (bug 641024) and others think. Having a generic way to delays streams sounds nicer. I also checked and the audiofiter elements do handle the latency query. Maybe the issue you have is that adder does not care about timestamps and latency. It just mixes samples as they come.
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #8) > > Should I put this element in a standalone plugin of the same name? > > Maybe, at least change the classification. "Filter/Effect/Audio" hints that it > is an effect. I would like to see what Thiago (bug 641024) and others think. > Having a generic way to delays streams sounds nicer. At this time, should I prepare a new patch with a standalone plugin, or should I wait further? > I also checked and the audiofiter elements do handle the latency query. Maybe > the issue you have is that adder does not care about timestamps and latency. It > just mixes samples as they come. Indeed.
Created attachment 191988 [details] [review] proposed patch for gst-plugins-bad Patch moved from gst-plugins-good to gst-plugins-bad.
Comment on attachment 191988 [details] [review] proposed patch for gst-plugins-bad This needs to be updated to 1.0, and then can be added to the audiofxbad plugin as a new element. The samples property should be called delay, and should be in nanoseconds for consistency. Sorry for not reviewing this patch earlier :(
Any plans to update this patch? A simple delay line can also be implemented with the audioecho element btw
(In reply to comment #15) > Any plans to update this patch? No, I'm afraid not. Sorry.
There's also the offset property on pads now in 1.x fwiw.
Lets close this then.