James Courtier-Dutton wrote:
> Reimar D=F6ffinger wrote:
>> On Wed, Oct 12, 2005 at 07:56:24PM -0300, Miguel Freitas wrote:
>>> as some must be aware, xine's realtime resampler (linear
>>> interpolation) may produce sound artifacts (a sort of aliasing). Ed
>>> Wildgoose even offered to write a plugin based on libsamplerate to fi=
>> Using libavcodec's resampler might be an even more interesting option,
>> since it wouldn't add an extra dependency. At least for low bitrates i=
>> seems quite good, for anything else my ears are the weakest link it=20
>> Reimar D=F6ffinger
> The latest xine-lib cvs can automatically detect if the sound card can=20
> do resampling in hardware or not, and if not, xine does it's own=20
> We need a resampler that we can throw one sample at a time. If=20
> libsamplerate can do that instead of block sample rate converter, then=20
> it would be a good idea to add to xine-lib.
It's still high on my list of things I would like to do! Especially now=20
I am looking at offering some of this stuff commercially (idea of a=20
media box is on the cards).
I guess libsamplerate can operate a sample at a time, but the CPU load=20
would be higher as a result I should think.
However, I am not quite sure what reason there would be to operate at=20
the sample level? Surely the data arrives in a block?
libsamplerate offers several engines of varying speed. The fastest is a=20
linear resampler, and it would be interesting to compare this with the=20
xine linear resampler because the existing one does seem to be very=20
good. Then you have several levels of quality using sinc resampling=20
which have various tradeoffs in quality versus speed.
I used libsamplerate in mythtv and at full quality it has a fairly high=20
CPU requirement (5-10% of a P2.8Ghz). However, it's within what should=20
be quite reasonable for a modern box I think? mplayer wouldn't tolerate=20
it because it would stop you playing a DVD on your wristwatch, but I=20
think xine has a different target market?!
There is also a resampler in lavc. This was written in response to my=20
attempts to push libsamplerate on mplayer (because their old resampler=20
was horrible). It has very low CPU requirements, but the author is quite=20
unfriendly about discussing the details and other than fixing the odd=20
bug it's hard to know what the parameters are and whether the quality=20
should be good for a certain set of params or not. Basically badly=20
Personally I would suggest we just do what we did with Myth which is to=20
fold the libsamplerate code into a xine subfolder and therefore=20
distribute it with xine. It's written in very portable C code, and=20
doesn't change very often. The whole code base strips down to just a=20
few files in practice (see the Mythtv usage for an example).
Otherwise I guess we could just make it a compile time dependency
The nice things about libsamplerate are:
- Documented, published and studied (and considered high quality by the=20
guys on the dsp mailing list)
- simple API (initialise it, then you just call "process" passing in=20
some pointers to your input and output buffers. Job done)
My personal xine dev list includes porting the mplayer Jack driver (from=20
Reimar) to xine and including this resampler. Probably not going to=20
happen in the next few weeks though.