[pulseaudio-discuss] GSoC Proposal: Resampling Improvements

[Tanu Kaskinen]

On Sat, 2013-04-27 at 13:44 +0200, Damir Jelić wrote:
> On Mon, Apr 22, 2013 at 06:33:08PM +0200, Peter Meerwald wrote:
> > Hello, 
> > 
> > > > > > > By "libresample", I guess you mean "libsamplerate". Peter can correct me
> > > > > > > if I'm intepreting him wrong, but my understanding is that libsamplerate
> > > > > > > was only mentioned as an example of a resampler with a problematic
> > > > > > > license. I don't know either what should be done about it - perhaps the
> > > > > > > idea was to compare the different resamplers, and if it turns out that
> > > > > > > we don't have any good reason to keep using libsamplerate, we could drop
> > > > > > > that code.
> > 
> > > > libsamplerate was mentioned because of the GPL license;
> > > > to work around, a loadable module interface could be offered, so the user 
> > > > can decide
> > 
> > > This sounds like a lot of complexity for little gain. What is wrong with
> > > compile time switches/options?
> > 
> > maybe yes; depends on how many resamplers there will be
> > 
> > a loadable module interface enforces a stricter and more stable interface, 
> > which may be a good thing
> > 
> > some refactoring is in place anyway, so depends how far we want to take it
> > 
> 
> So I checked this out a little bit and I think I could also add this to
> my proposal.
> 
> Here is what I came up with:
>     - make the pa_resampler structure implementation agnostic
>     - replace the static resampling method table with a hashmap or
>       idxset
>     - move the resampler methods to modules and let them register
>       themself inside with the core
> 
> How does that sound to you?
> 
> What do the other devs think about this?

So the motivation for this was that libsamplerate is licensed under GPL,
and "a loadable module interface could be offered, so the user can
decide". That implies that the libsamplerate resampler module would be
built and distributed separately from the distro's PulseAudio. The
resampler module interface would have to be separate from the normal
module interface, because the normal module interface (which uses a
pa_module pointer to access all the rest of the system) has no stability
guarantees. A distro can change the core APIs at any time (perhaps as a
part of a patch that fixes a bug), and if all modules aren't built with
the new core API, there's a risk that separately built modules won't
work anymore.

Are there some real world examples, where a distro disables some
resampler that its users would like to use? If not, I don't really see
the point of moving resamplers into modules.

-- 
Tanu

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.