GNOME Bugzilla – Bug 594381
audiofirfilter: Implement FFT convolution
Last modified: 2010-01-14 16:22:23 UTC
I'm developing an application with Gstreamer and the BeagleBoard and I want to use the plugins Audiofirfilter and Audioecho (Audiofx). They are already in the unstable version of angstrom to update, but I've installed them. With the audioecho I've no problem, it functions very well but when I try to use the audiofirfilter I can't hear anything despite receiving no error message. When audiofirfilter will be ready for beagleboard? Thanks.
audiofirfilter is not meant to be used without parameters. To use it you have to provide filter coefficients via the "kernel" GObject property, otherwise it will work in passthrough mode. Take a look at tests/examples/audiofx/firfilter-example.c for an example about how to use it.
Thank you four your answer but I'm using the "kernel" property. In fact, I have test the same application with my PC Desktop and it functions properly. And in the beagleboard, the problem is that, even in passthrough mode, there is no audio output when I use the audiofirfilter.
Ah ok, could you attach your application or even better a minimal testcase? Also what do you mean with no audio output? audiofirfilter doesn't even push any buffers downstream?
Created attachment 142672 [details] Testcase for audiofirfilter
Created attachment 142673 [details] An stereo filter for the testcase application
Hello again, I've attached the testcase I use and also the filter I'm loading in the kernel property. As you will see, I'm trying to create an stereo filter and the audio sink I use is an mp3 file called "introduction.mp3". The compilation command I use: gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) filter.c -o filter And in reference to the audio output, yes, audiofirfilter doesn't even push any buffers. Thank you again.
(You probably want to change the kernels on the rate-changed signal as they're sample rate dependended in general) The sample looks fine, could you attach GST_DEBUG=5 logs from a run on the OMAP?
Created attachment 142675 [details] The output debug for the audiofirfilter testcase
Here is a sample of the debug output with passthrough mode of the audiofirfilter. I know the best use of the kernel property is to change it on the rate-changed signal, but I'm starting with the development and is the quick way to test the plugins.
The debug output is only a sample at the beginning as it's very long and I missed the first part. If it is necessary to get longer, ask for it.
That debug output doesn't help much, it's only the type registration and not the interesting part. What is needed is the end (i.e. where it hangs). If it's too large you could also attach a bz2 compressed version if you want :)
Although there was also a problem with the amplitude, the main error came from the length of the filter (I had 512). It seems that beagleboard doesn't support more than 32 coeffs filter length. Now, with that length (32), audiofirfilter goes well in the beagleboard. Thanks for your support.
Do you think it could be possible to optimize the filter or to do something for the audiofirfilter so it could support bigger lengths?
Oh, there's no limitation to the kernel length but processing time is quadratic in kernel length IIRC (or even worse). So the problem might be, that it simply takes too long on OMAP and because of that you don't see any results. Could you try some other kernel lengths to see if that seems to be the problem? Start from 32 and increase it one-by-one to see if everything becomes slower and slower and then nothing seems to happen anymore. Also please check with 512 if the CPU is completely utilizied while it looks like it hangs and please attach gdb to the process to see if it really hangs in the fir filter convolution. One possible solution for this would be to implement FFT convolution in the filter. Then the processing wouldn't be quadratic in kernel length anymore but O(n*log(n)) with n=kernel length.
I try other kernel lengths from 32 to 512. With 32 it functions with fluency, but with 64 it starts to hear by parts, with 128 you hear some sound but anything understandable... and it gets worse with the increase in filter length, so I think that it's a time problem, as you say. I will check the cpu.
Sorry for the delay. Finally I checked the CPU and you were right, with 64 coeffs the CPU is at 80% but with 128 coeffs is completely blocked with the process. I think FFT implementation is a great idea. When do you expect it to be updated? Thanks.
When I find time to do it :) It'd be great if someone else could work on that, then it'll be finished much faster. This has a very low priority on my TODO list right now. For details on what exactly needs to be done: http://www.dspguide.com/ch18.htm or every random Google page that matches "fast convolution" or "fft convolution" ;)
Isn't this fixed?
Yes ;)