GNOME Bugzilla – Bug 558124
[PLUGIN-MOVE] Move speexresample as audioresample2 to -base
Last modified: 2008-11-27 16:58:42 UTC
IMHO we should get speexresample into -base and renamed to audioresample2 for the next release. There is a bug to be solved before (bug #508029) but afterwards I see no reason not to do it... Reasons for this are: - speexresample already does lowpassing for downsampling, adding this to audioresample is more work than necessary IMHO (bug #346218) - speexresample is 3-10 times faster than audioresample while theoretically providing better quality (bug #385061) - speexresample supports rate conversion with a factor > 2 (bug #116051) We can't simply exchange the plugins because audioresample has a filter-length parameter while speexresample has a quality parameter (which adjusts the filter length among other things)
Ok, now speexresample doesn't have bug #508029 anymore and supports all raw audio formats we have. We should get it moved now for the next release :)
Of course, if we move and rename it, all references to "audioresample" should be changed to "audioresample2", i.e. in docs and playbin.
Sounds like a good idea to me, given that chances are (imo) rather slim that anyone's going to make our current audioresample not suck any time soon. I'm wondering: - does setting the 'filter-length' to a specific value imply something directly quantifiable about the behaviour of the element in the pipeline (e.g. is there a direct relationship between the filter-length value and max. latency or so)? - if not, maybe we could just add a filter-length property to speexaudioresample and translate that to some roughly equivalent quality value, and then just replace the old audioresample with this, instead of having an audioresample2? (this should be done after the release then though imo) - either way, I think we should not make playbin use the new resample so shortly before the release, but give it some testing in cvs first. - (also, minor point, but I'm not sure if we should really fix up all the example pipelines, wouldn't that make them unnecessarily confusing for beginners?)
The filter-length is twice the latency (in samples). The problem here is, that audioresample allows a filter length between 0 and 1<<31 while speexresample hides the filter length internally behind the quality parameter. quality 0 for example has a filter length of 8, quality 10 is 256 (quality also has influence on a few other internal parameters). So we could map the filter length to the quality and simply have everything above 256 map to quality 10. Then we could replace audioresample by this without introducing a new element. Downside is, that we have a useless property but we can of course remove that in 0.11 then :) If this sounds fine for everybody else we should do that instead of introducing audioresample2. For when to do the switch, I'd say now is a good time as the release is still about one month in the future (and on IRC Tim said that he agrees that one month is enough). We just need to get it moved to -base ASAP now. I'd propose to move old audioresample to audioresample-old then, let it register as audioresample-old and move speexresample to -base/gst/audioresample and rename everything.
This is fixed now in -base and -bad CVS.