Re: Quality resampling code for libasound

[Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>]

>> The quality is similar to what you get with libsamplerate, but the
>> license is BSD, so there should be no issue using it within libasound.
>> There are 11 quality settings (0-10) and even the lowest quality
>> provided is already miles better than the linear interpolation currently
>> being done (which creates insane amounts of aliasing when doing things
>> like upsampling from 8 kHz to 48 kHz). I'm also willing to help whoever
>> is interested in adding support for it.
> 
> Basically I'd like to keep the default resampling code in alsa-lib as
> simple as possible.  So, I recommend you to impelment this first as an
> external plugin in alsa-plugins package just like like libsamplerate
> one.

What?? I hope you're joking here. It's one thing if you don't want my
code for a reason or another, but being happy to keep things as they are
currently is just insane. What libasound does is not resampling, it's
audio mutilation, plain and simple. It's not an audiophile thing we're
talking about. The aliasing is so bad people notice it even with speech
(which usually tolerates a lot of abuse) and think it's an application
bug (e.g. http://www.mail-archive.com/ekiga-list@gnome.org/msg01316.html
). This is only getting worse as people get new machines with HDA-based
cards that only do 44.1/48 kHz, so it'll become even more embarrassing.
Do you expect most Linux users who use a soundcard to know that they
need a plugin to have their cards actually reproduce sounds properly?

Oh, and BTW from what I see libasound is at least 80k lines of code and
my resampling is 1000 lines -- of which you can probably remove half if
you want to keep things simple. I fail to see what the problem is.

>> Partly related to that is another annoyance I found in the plug:
>> converters. The conversion between 24-bit samples into 16-bit samples
>> appears to be done by truncating rather than by rounding, which
>> introduces more quantisation noise and also a small DC bias. The fix for
>> that is fairly simple: in all the places where you have something like:
>> out[i] = in[i] >> 8;
>> it should be replaced by:
>> out[i] = (in[i]+128) >> 8;
> 
> Yes, that's a thing to be fixed.

Thanks.

>> I would have submitted a patch for that, but I was never able to figure
>> out how that part of the code works.
> 
> Better to see the patch first, then discuss further :)

Well, I'll submit the 3-line patch if you can indicate where the change
actually goes. There are lots of places that do similar shifts and I'm
not quite sure which are the right ones.

	Jean-Marc

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV