At Mon, 19 Feb 2007 23:54:15 +1100, Jean-Marc Valin wrote: > > >> 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@xxxxxxxxx/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? Yes. Of course, we can do eventually merge, but let's see the result at first. I don't want to be a politician who promisses the vapor things. > 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. Nothing bug misleading. > >> 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. That's why I asked you kick off the patch first... 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
