From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Quality resampling code for libasound Date: Mon, 19 Feb 2007 13:23:53 +0100 Message-ID: References: <45D92131.50601@usherbrooke.ca> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45D92131.50601@usherbrooke.ca> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@lists.sourceforge.net Errors-To: alsa-devel-bounces@lists.sourceforge.net To: Jean-Marc Valin Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Mon, 19 Feb 2007 15:01:53 +1100, Jean-Marc Valin wrote: > > Hi everyone, > > After bitching for a while about the poor quality of the resampler used > by the plug: interface, I've finally put code where my mouth is and > wrote a BSD-licensed resampler. While the code lives within the Speex > project, it's trivial to get out of there. All you need to grab is: > http://svn.xiph.org/trunk/speex/include/speex/speex_resampler.h > http://svn.xiph.org/trunk/speex/libspeex/resample.c > and then you need to compile with -DOUTSIDE_SPEEX > > 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. > 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. > 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 :) thanks, Takashi ------------------------------------------------------------------------- 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