* Quality resampling code for libasound @ 2007-02-19 4:01 Jean-Marc Valin 2007-02-19 12:23 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-19 4:01 UTC (permalink / raw) To: alsa-devel 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. 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; I would have submitted a patch for that, but I was never able to figure out how that part of the code works. Jean-Marc P.S. Please keep me in CC since I'm not subscribed to the list. ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 4:01 Quality resampling code for libasound Jean-Marc Valin @ 2007-02-19 12:23 ` Takashi Iwai 2007-02-19 12:54 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-02-19 12:23 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 12:23 ` Takashi Iwai @ 2007-02-19 12:54 ` Jean-Marc Valin 2007-02-19 13:10 ` Takashi Iwai 2007-02-19 13:11 ` Prakash Punnoor 0 siblings, 2 replies; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-19 12:54 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel >> 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 12:54 ` Jean-Marc Valin @ 2007-02-19 13:10 ` Takashi Iwai 2007-02-19 13:38 ` Jean-Marc Valin 2007-02-19 13:11 ` Prakash Punnoor 1 sibling, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-02-19 13:10 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel 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@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? 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 13:10 ` Takashi Iwai @ 2007-02-19 13:38 ` Jean-Marc Valin 2007-02-19 13:47 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-19 13:38 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 1367 bytes --] >> 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? > > 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. As I said in my original post, I'm quite willing to help whoever is interested in integrating this code in libasound -- but at this point, I'm not planning on writing the plugin itself. Any taker? > That's why I asked you kick off the patch first... Patch attached. This is based on my (very little) understanding of the sample conversion code, so it could also be just dead wrong. Jean-Marc [-- Attachment #2: plug_shift.patch --] [-- Type: text/x-patch, Size: 15548 bytes --] --- plugin_ops.h.old 2006-12-08 01:10:28.000000000 +1100 +++ plugin_ops.h 2007-02-20 00:29:14.000000000 +1100 @@ -256,14 +256,14 @@ conv_xxx1_009x: as_u32(dst) = sx24s((u_int32_t)(as_u8c(src) ^ 0x80) << 8); goto CONV_END; conv_xxx1_9000: as_u32(dst) = (u_int32_t)(as_u8c(src) ^ 0x80) << 24; goto CONV_END; conv_xxx1_0009: as_u32(dst) = (u_int32_t)(as_u8c(src) ^ 0x80); goto CONV_END; -conv_xx12_xxx1: as_u8(dst) = as_u16c(src) >> 8; goto CONV_END; +conv_xx12_xxx1: as_u8(dst) = as_u16c(src)+128 >> 8; goto CONV_END; conv_xx12_xx12: as_u16(dst) = as_u16c(src); goto CONV_END; conv_xx12_xx21: as_u16(dst) = bswap_16(as_u16c(src)); goto CONV_END; conv_xx12_x120: as_u32(dst) = sx24((u_int32_t)as_u16c(src) << 8); goto CONV_END; conv_xx12_021x: as_u32(dst) = sx24s((u_int32_t)bswap_16(as_u16c(src)) << 8); goto CONV_END; conv_xx12_1200: as_u32(dst) = (u_int32_t)as_u16c(src) << 16; goto CONV_END; conv_xx12_0021: as_u32(dst) = (u_int32_t)bswap_16(as_u16c(src)); goto CONV_END; -conv_xx12_xxx9: as_u8(dst) = (as_u16c(src) >> 8) ^ 0x80; goto CONV_END; +conv_xx12_xxx9: as_u8(dst) = (as_u16c(src)+128 >> 8) ^ 0x80; goto CONV_END; conv_xx12_xx92: as_u16(dst) = as_u16c(src) ^ 0x8000; goto CONV_END; conv_xx12_xx29: as_u16(dst) = bswap_16(as_u16c(src)) ^ 0x80; goto CONV_END; conv_xx12_x920: as_u32(dst) = sx24((u_int32_t)(as_u16c(src) ^ 0x8000) << 8); goto CONV_END; @@ -282,57 +282,57 @@ conv_xx12_01Ax: as_u32(dst) = sx24s((u_int32_t)(as_u16c(src) ^ 0x80) << 8); goto CONV_END; conv_xx12_A100: as_u32(dst) = (u_int32_t)bswap_16(as_u16c(src) ^ 0x80) << 16; goto CONV_END; conv_xx12_001A: as_u32(dst) = (u_int32_t)(as_u16c(src) ^ 0x80); goto CONV_END; -conv_x123_xxx1: as_u8(dst) = as_u32c(src) >> 16; goto CONV_END; -conv_x123_xx12: as_u16(dst) = as_u32c(src) >> 8; goto CONV_END; -conv_x123_xx21: as_u16(dst) = bswap_16(as_u32c(src) >> 8); goto CONV_END; +conv_x123_xxx1: as_u8(dst) = as_u32c(src)+32768 >> 16; goto CONV_END; +conv_x123_xx12: as_u16(dst) = as_u32c(src)+128 >> 8; goto CONV_END; +conv_x123_xx21: as_u16(dst) = bswap_16(as_u32c(src)+128 >> 8); goto CONV_END; conv_x123_x123: as_u32(dst) = sx24(as_u32c(src)); goto CONV_END; conv_x123_321x: as_u32(dst) = sx24s(bswap_32(as_u32c(src))); goto CONV_END; conv_x123_1230: as_u32(dst) = as_u32c(src) << 8; goto CONV_END; -conv_x123_0321: as_u32(dst) = bswap_32(as_u32c(src)) >> 8; goto CONV_END; -conv_x123_xxx9: as_u8(dst) = (as_u32c(src) >> 16) ^ 0x80; goto CONV_END; -conv_x123_xx92: as_u16(dst) = (as_u32c(src) >> 8) ^ 0x8000; goto CONV_END; -conv_x123_xx29: as_u16(dst) = bswap_16(as_u32c(src) >> 8) ^ 0x80; goto CONV_END; +conv_x123_0321: as_u32(dst) = bswap_32(as_u32c(src))+128 >> 8; goto CONV_END; +conv_x123_xxx9: as_u8(dst) = (as_u32c(src)+32768 >> 16) ^ 0x80; goto CONV_END; +conv_x123_xx92: as_u16(dst) = (as_u32c(src)+128 >> 8) ^ 0x8000; goto CONV_END; +conv_x123_xx29: as_u16(dst) = bswap_16(as_u32c(src)+128 >> 8) ^ 0x80; goto CONV_END; conv_x123_x923: as_u32(dst) = sx24(as_u32c(src) ^ 0x800000); goto CONV_END; conv_x123_329x: as_u32(dst) = sx24s(bswap_32(as_u32c(src)) ^ 0x8000); goto CONV_END; conv_x123_9230: as_u32(dst) = (as_u32c(src) ^ 0x800000) << 8; goto CONV_END; -conv_x123_0329: as_u32(dst) = (bswap_32(as_u32c(src)) >> 8) ^ 0x80; goto CONV_END; -conv_123x_xxx3: as_u8(dst) = (as_u32c(src) >> 8) & 0xff; goto CONV_END; -conv_123x_xx32: as_u16(dst) = bswap_16(as_u32c(src) >> 8); goto CONV_END; -conv_123x_xx23: as_u16(dst) = (as_u32c(src) >> 8) & 0xffff; goto CONV_END; +conv_x123_0329: as_u32(dst) = (bswap_32(as_u32c(src))+128 >> 8) ^ 0x80; goto CONV_END; +conv_123x_xxx3: as_u8(dst) = (as_u32c(src)+128 >> 8) & 0xff; goto CONV_END; +conv_123x_xx32: as_u16(dst) = bswap_16(as_u32c(src)+128 >> 8); goto CONV_END; +conv_123x_xx23: as_u16(dst) = (as_u32c(src)+128 >> 8) & 0xffff; goto CONV_END; conv_123x_x321: as_u32(dst) = sx24(bswap_32(as_u32c(src))); goto CONV_END; conv_123x_123x: as_u32(dst) = sx24s(as_u32c(src)); goto CONV_END; conv_123x_3210: as_u32(dst) = bswap_32(as_u32c(src)) << 8; goto CONV_END; -conv_123x_0123: as_u32(dst) = as_u32c(src) >> 8; goto CONV_END; -conv_123x_xxxB: as_u8(dst) = ((as_u32c(src) >> 8) & 0xff) ^ 0x80; goto CONV_END; -conv_123x_xxB2: as_u16(dst) = bswap_16((as_u32c(src) >> 8) ^ 0x80); goto CONV_END; -conv_123x_xx2B: as_u16(dst) = ((as_u32c(src) >> 8) & 0xffff) ^ 0x80; goto CONV_END; +conv_123x_0123: as_u32(dst) = as_u32c(src)+128 >> 8; goto CONV_END; +conv_123x_xxxB: as_u8(dst) = ((as_u32c(src)+128 >> 8) & 0xff) ^ 0x80; goto CONV_END; +conv_123x_xxB2: as_u16(dst) = bswap_16((as_u32c(src)+128 >> 8) ^ 0x80); goto CONV_END; +conv_123x_xx2B: as_u16(dst) = ((as_u32c(src)+128 >> 8) & 0xffff) ^ 0x80; goto CONV_END; conv_123x_xB21: as_u32(dst) = sx24(bswap_32(as_u32c(src)) ^ 0x800000); goto CONV_END; conv_123x_12Bx: as_u32(dst) = sx24s(as_u32c(src) ^ 0x8000); goto CONV_END; conv_123x_B210: as_u32(dst) = bswap_32(as_u32c(src) ^ 0x8000) << 8; goto CONV_END; -conv_123x_012B: as_u32(dst) = (as_u32c(src) >> 8) ^ 0x80; goto CONV_END; -conv_1234_xxx1: as_u8(dst) = as_u32c(src) >> 24; goto CONV_END; -conv_1234_xx12: as_u16(dst) = as_u32c(src) >> 16; goto CONV_END; -conv_1234_xx21: as_u16(dst) = bswap_16(as_u32c(src) >> 16); goto CONV_END; -conv_1234_x123: as_u32(dst) = sx24(as_u32c(src) >> 8); goto CONV_END; +conv_123x_012B: as_u32(dst) = (as_u32c(src)+128 >> 8) ^ 0x80; goto CONV_END; +conv_1234_xxx1: as_u8(dst) = as_u32c(src)+8388608 >> 24; goto CONV_END; +conv_1234_xx12: as_u16(dst) = as_u32c(src)+32768 >> 16; goto CONV_END; +conv_1234_xx21: as_u16(dst) = bswap_16(as_u32c(src)+32768 >> 16); goto CONV_END; +conv_1234_x123: as_u32(dst) = sx24(as_u32c(src)+128 >> 8); goto CONV_END; conv_1234_321x: as_u32(dst) = sx24s(bswap_32(as_u32c(src)) << 8); goto CONV_END; conv_1234_1234: as_u32(dst) = as_u32c(src); goto CONV_END; conv_1234_4321: as_u32(dst) = bswap_32(as_u32c(src)); goto CONV_END; -conv_1234_xxx9: as_u8(dst) = (as_u32c(src) >> 24) ^ 0x80; goto CONV_END; -conv_1234_xx92: as_u16(dst) = (as_u32c(src) >> 16) ^ 0x8000; goto CONV_END; -conv_1234_xx29: as_u16(dst) = bswap_16(as_u32c(src) >> 16) ^ 0x80; goto CONV_END; -conv_1234_x923: as_u32(dst) = sx24((as_u32c(src) >> 8) ^ 0x800000); goto CONV_END; +conv_1234_xxx9: as_u8(dst) = (as_u32c(src)+8388608 >> 24) ^ 0x80; goto CONV_END; +conv_1234_xx92: as_u16(dst) = (as_u32c(src)+32768 >> 16) ^ 0x8000; goto CONV_END; +conv_1234_xx29: as_u16(dst) = bswap_16(as_u32c(src)+32768 >> 16) ^ 0x80; goto CONV_END; +conv_1234_x923: as_u32(dst) = sx24((as_u32c(src)+128 >> 8) ^ 0x800000); goto CONV_END; conv_1234_329x: as_u32(dst) = sx24s((bswap_32(as_u32c(src)) ^ 0x80) << 8); goto CONV_END; conv_1234_9234: as_u32(dst) = as_u32c(src) ^ 0x80000000; goto CONV_END; conv_1234_4329: as_u32(dst) = bswap_32(as_u32c(src)) ^ 0x80; goto CONV_END; conv_1234_xxx4: as_u8(dst) = as_u32c(src) & 0xff; goto CONV_END; conv_1234_xx43: as_u16(dst) = bswap_16(as_u32c(src)); goto CONV_END; conv_1234_xx34: as_u16(dst) = as_u32c(src) & 0xffff; goto CONV_END; -conv_1234_x432: as_u32(dst) = sx24(bswap_32(as_u32c(src)) >> 8); goto CONV_END; +conv_1234_x432: as_u32(dst) = sx24(bswap_32(as_u32c(src))+128 >> 8); goto CONV_END; conv_1234_234x: as_u32(dst) = sx24s(as_u32c(src) << 8); goto CONV_END; conv_1234_xxxC: as_u8(dst) = (as_u32c(src) & 0xff) ^ 0x80; goto CONV_END; conv_1234_xxC3: as_u16(dst) = bswap_16(as_u32c(src) ^ 0x80); goto CONV_END; conv_1234_xx3C: as_u16(dst) = (as_u32c(src) & 0xffff) ^ 0x80; goto CONV_END; -conv_1234_xC32: as_u32(dst) = sx24((bswap_32(as_u32c(src)) >> 8) ^ 0x800000); goto CONV_END; +conv_1234_xC32: as_u32(dst) = sx24((bswap_32(as_u32c(src))+128 >> 8) ^ 0x800000); goto CONV_END; conv_1234_23Cx: as_u32(dst) = sx24s((as_u32c(src) ^ 0x80) << 8); goto CONV_END; conv_1234_C321: as_u32(dst) = bswap_32(as_u32c(src) ^ 0x80); goto CONV_END; conv_1234_123C: as_u32(dst) = as_u32c(src) ^ 0x80; goto CONV_END; @@ -382,26 +382,26 @@ get16_12_92: sample = as_u16c(src) ^ 0x8000; goto GET16_END; get16_12_21: sample = bswap_16(as_u16c(src)); goto GET16_END; get16_12_A1: sample = bswap_16(as_u16c(src) ^ 0x80); goto GET16_END; -get16_0123_12: sample = as_u32c(src) >> 8; goto GET16_END; -get16_0123_92: sample = (as_u32c(src) >> 8) ^ 0x8000; goto GET16_END; -get16_1230_32: sample = bswap_16(as_u32c(src) >> 8); goto GET16_END; -get16_1230_B2: sample = bswap_16((as_u32c(src) >> 8) ^ 0x80); goto GET16_END; -get16_1234_12: sample = as_u32c(src) >> 16; goto GET16_END; -get16_1234_92: sample = (as_u32c(src) >> 16) ^ 0x8000; goto GET16_END; +get16_0123_12: sample = as_u32c(src)+128 >> 8; goto GET16_END; +get16_0123_92: sample = (as_u32c(src)+128 >> 8) ^ 0x8000; goto GET16_END; +get16_1230_32: sample = bswap_16(as_u32c(src)+128 >> 8); goto GET16_END; +get16_1230_B2: sample = bswap_16((as_u32c(src)+128 >> 8) ^ 0x80); goto GET16_END; +get16_1234_12: sample = as_u32c(src)+32768 >> 16; goto GET16_END; +get16_1234_92: sample = (as_u32c(src)+32768 >> 16) ^ 0x8000; goto GET16_END; get16_1234_43: sample = bswap_16(as_u32c(src)); goto GET16_END; get16_1234_C3: sample = bswap_16(as_u32c(src) ^ 0x80); goto GET16_END; -get16_123_12: sample = _get_triple(src) >> 8; goto GET16_END; -get16_123_92: sample = (_get_triple(src) >> 8) ^ 0x8000; goto GET16_END; -get16_123_32: sample = _get_triple_s(src) >> 8; goto GET16_END; -get16_123_B2: sample = (_get_triple_s(src) >> 8) ^ 0x8000; goto GET16_END; -get16_123_12_20: sample = _get_triple(src) >> 4; goto GET16_END; -get16_123_92_20: sample = (_get_triple(src) >> 4) ^ 0x8000; goto GET16_END; -get16_123_32_20: sample = _get_triple_s(src) >> 4; goto GET16_END; -get16_123_B2_20: sample = (_get_triple_s(src) >> 4) ^ 0x8000; goto GET16_END; -get16_123_12_18: sample = _get_triple(src) >> 2; goto GET16_END; -get16_123_92_18: sample = (_get_triple(src) >> 2) ^ 0x8000; goto GET16_END; -get16_123_32_18: sample = _get_triple_s(src) >> 2; goto GET16_END; -get16_123_B2_18: sample = (_get_triple_s(src) >> 2) ^ 0x8000; goto GET16_END; +get16_123_12: sample = _get_triple(src)+128 >> 8; goto GET16_END; +get16_123_92: sample = (_get_triple(src)+128 >> 8) ^ 0x8000; goto GET16_END; +get16_123_32: sample = _get_triple_s(src)+128 >> 8; goto GET16_END; +get16_123_B2: sample = (_get_triple_s(src)+128 >> 8) ^ 0x8000; goto GET16_END; +get16_123_12_20: sample = _get_triple(src)+8 >> 4; goto GET16_END; +get16_123_92_20: sample = (_get_triple(src)+8 >> 4) ^ 0x8000; goto GET16_END; +get16_123_32_20: sample = _get_triple_s(src)+8 >> 4; goto GET16_END; +get16_123_B2_20: sample = (_get_triple_s(src)+8 >> 4) ^ 0x8000; goto GET16_END; +get16_123_12_18: sample = _get_triple(src)+2 >> 2; goto GET16_END; +get16_123_92_18: sample = (_get_triple(src)+2 >> 2) ^ 0x8000; goto GET16_END; +get16_123_32_18: sample = _get_triple_s(src)+2 >> 2; goto GET16_END; +get16_123_B2_18: sample = (_get_triple_s(src)+2 >> 2) ^ 0x8000; goto GET16_END; } #endif @@ -429,8 +429,8 @@ #ifdef PUT16_END while (0) { -put16_12_1: as_u8(dst) = sample >> 8; goto PUT16_END; -put16_12_9: as_u8(dst) = (sample >> 8) ^ 0x80; goto PUT16_END; +put16_12_1: as_u8(dst) = sample+128 >> 8; goto PUT16_END; +put16_12_9: as_u8(dst) = (sample+128 >> 8) ^ 0x80; goto PUT16_END; put16_12_12: as_u16(dst) = sample; goto PUT16_END; put16_12_92: as_u16(dst) = sample ^ 0x8000; goto PUT16_END; put16_12_21: as_u16(dst) = bswap_16(sample); goto PUT16_END; @@ -500,8 +500,8 @@ get32_12_A100: sample = (u_int32_t)bswap_16(as_u16c(src) ^ 0x80) << 16; goto GET32_END; get32_0123_1230: sample = as_u32c(src) << 8; goto GET32_END; get32_0123_9230: sample = (as_u32c(src) << 8) ^ 0x80000000; goto GET32_END; -get32_1230_3210: sample = bswap_32(as_u32c(src) >> 8); goto GET32_END; -get32_1230_B210: sample = bswap_32((as_u32c(src) >> 8) ^ 0x80); goto GET32_END; +get32_1230_3210: sample = bswap_32(as_u32c(src)+128 >> 8); goto GET32_END; +get32_1230_B210: sample = bswap_32((as_u32c(src)+128 >> 8) ^ 0x80); goto GET32_END; get32_1234_1234: sample = as_u32c(src); goto GET32_END; get32_1234_9234: sample = as_u32c(src) ^ 0x80000000; goto GET32_END; get32_1234_4321: sample = bswap_32(as_u32c(src)); goto GET32_END; @@ -568,32 +568,32 @@ #ifdef PUT32_END while (0) { -put32_1234_1: as_u8(dst) = sample >> 24; goto PUT32_END; -put32_1234_9: as_u8(dst) = (sample >> 24) ^ 0x80; goto PUT32_END; -put32_1234_12: as_u16(dst) = sample >> 16; goto PUT32_END; -put32_1234_92: as_u16(dst) = (sample >> 16) ^ 0x8000; goto PUT32_END; -put32_1234_21: as_u16(dst) = bswap_16(sample >> 16); goto PUT32_END; -put32_1234_29: as_u16(dst) = bswap_16(sample >> 16) ^ 0x80; goto PUT32_END; -put32_1234_0123: as_u32(dst) = sx24(sample >> 8); goto PUT32_END; -put32_1234_0923: as_u32(dst) = sx24((sample >> 8) ^ 0x800000); goto PUT32_END; +put32_1234_1: as_u8(dst) = sample+8388608 >> 24; goto PUT32_END; +put32_1234_9: as_u8(dst) = (sample+8388608 >> 24) ^ 0x80; goto PUT32_END; +put32_1234_12: as_u16(dst) = sample+32768 >> 16; goto PUT32_END; +put32_1234_92: as_u16(dst) = (sample+32768 >> 16) ^ 0x8000; goto PUT32_END; +put32_1234_21: as_u16(dst) = bswap_16(sample+32768 >> 16); goto PUT32_END; +put32_1234_29: as_u16(dst) = bswap_16(sample+32768 >> 16) ^ 0x80; goto PUT32_END; +put32_1234_0123: as_u32(dst) = sx24(sample+128 >> 8); goto PUT32_END; +put32_1234_0923: as_u32(dst) = sx24((sample+128 >> 8) ^ 0x800000); goto PUT32_END; put32_1234_3210: as_u32(dst) = sx24s(bswap_32(sample) << 8); goto PUT32_END; put32_1234_3290: as_u32(dst) = sx24s((bswap_32(sample) ^ 0x80) << 8); goto PUT32_END; put32_1234_1234: as_u32(dst) = sample; goto PUT32_END; put32_1234_9234: as_u32(dst) = sample ^ 0x80000000; goto PUT32_END; put32_1234_4321: as_u32(dst) = bswap_32(sample); goto PUT32_END; put32_1234_4329: as_u32(dst) = bswap_32(sample) ^ 0x80; goto PUT32_END; -put32_1234_123: _put_triple(dst, sample >> 8); goto PUT32_END; -put32_1234_923: _put_triple(dst, (sample ^ 0x80000000) >> 8); goto PUT32_END; -put32_1234_321: _put_triple_s(dst, sample >> 8); goto PUT32_END; -put32_1234_329: _put_triple_s(dst, (sample ^ 0x80000000) >> 8); goto PUT32_END; -put32_1234_123_20: _put_triple(dst, sample >> 12); goto PUT32_END; -put32_1234_923_20: _put_triple(dst, (sample ^ 0x80000000) >> 12); goto PUT32_END; -put32_1234_321_20: _put_triple_s(dst, sample >> 12); goto PUT32_END; -put32_1234_329_20: _put_triple_s(dst, (sample ^ 0x80000000) >> 12); goto PUT32_END; -put32_1234_123_18: _put_triple(dst, sample >> 14); goto PUT32_END; -put32_1234_923_18: _put_triple(dst, (sample ^ 0x80000000) >> 14); goto PUT32_END; -put32_1234_321_18: _put_triple_s(dst, sample >> 14); goto PUT32_END; -put32_1234_329_18: _put_triple_s(dst, (sample ^ 0x80000000) >> 14); goto PUT32_END; +put32_1234_123: _put_triple(dst, sample+128 >> 8); goto PUT32_END; +put32_1234_923: _put_triple(dst, (sample ^ 0x80000000)+128 >> 8); goto PUT32_END; +put32_1234_321: _put_triple_s(dst, sample+128 >> 8); goto PUT32_END; +put32_1234_329: _put_triple_s(dst, (sample ^ 0x80000000)+128 >> 8); goto PUT32_END; +put32_1234_123_20: _put_triple(dst, sample+2048 >> 12); goto PUT32_END; +put32_1234_923_20: _put_triple(dst, (sample ^ 0x80000000)+2048 >> 12); goto PUT32_END; +put32_1234_321_20: _put_triple_s(dst, sample+2048 >> 12); goto PUT32_END; +put32_1234_329_20: _put_triple_s(dst, (sample ^ 0x80000000)+2048 >> 12); goto PUT32_END; +put32_1234_123_18: _put_triple(dst, sample+8192 >> 14); goto PUT32_END; +put32_1234_923_18: _put_triple(dst, (sample ^ 0x80000000)+8192 >> 14); goto PUT32_END; +put32_1234_321_18: _put_triple_s(dst, sample+8192 >> 14); goto PUT32_END; +put32_1234_329_18: _put_triple_s(dst, (sample ^ 0x80000000)+8192 >> 14); goto PUT32_END; } #endif [-- Attachment #3: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #4: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 13:38 ` Jean-Marc Valin @ 2007-02-19 13:47 ` Takashi Iwai 2007-02-20 5:53 ` Jean-Marc Valin 2007-02-20 6:48 ` Jean-Marc Valin 0 siblings, 2 replies; 45+ messages in thread From: Takashi Iwai @ 2007-02-19 13:47 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel At Tue, 20 Feb 2007 00:38:16 +1100, Jean-Marc Valin wrote: > > >> 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? > > > > 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. > > As I said in my original post, I'm quite willing to help whoever is > interested in integrating this code in libasound -- but at this point, > I'm not planning on writing the plugin itself. Any taker? Well, did you take a look at alsa-plugins/rate/rate_samplerate.c? That's _much_ easier than rewrting alsa-lib pcm_rate.c. This is another reason I recommended the external plugin as a first attempt. (And we can change the default thing later on, for example, after checking whether it gets no performance drawback.) > > That's why I asked you kick off the patch first... > > Patch attached. This is based on my (very little) understanding of the > sample conversion code, so it could also be just dead wrong. I'll check it later. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 13:47 ` Takashi Iwai @ 2007-02-20 5:53 ` Jean-Marc Valin 2007-02-20 6:48 ` Jean-Marc Valin 1 sibling, 0 replies; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-20 5:53 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 832 bytes --] > Well, did you take a look at alsa-plugins/rate/rate_samplerate.c? > That's _much_ easier than rewrting alsa-lib pcm_rate.c. This is > another reason I recommended the external plugin as a first attempt. > (And we can change the default thing later on, for example, after > checking whether it gets no performance drawback.) Here's the plugin code. It's self-contained (includes my Public Parrot Hack code) and it's based on on the libsamplerate plugin. I've tested it and it seems to work right, but I'm not sure the code handles "fractional samples" perfectly. By that I mean that I don't see how the plugin is supposed to handle the fact that the number of output samples may vary even with the same number of input samples (e.g. downsampling 1024 samples by a factor of 3 may produce either 341 or 342 samples). Jean-Marc [-- Attachment #2: pph.tar.gz --] [-- Type: application/x-gzip, Size: 12287 bytes --] [-- Attachment #3: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #4: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 13:47 ` Takashi Iwai 2007-02-20 5:53 ` Jean-Marc Valin @ 2007-02-20 6:48 ` Jean-Marc Valin 2007-02-20 10:45 ` Takashi Iwai 1 sibling, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-20 6:48 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel > Well, did you take a look at alsa-plugins/rate/rate_samplerate.c? > That's _much_ easier than rewrting alsa-lib pcm_rate.c. This is > another reason I recommended the external plugin as a first attempt. > (And we can change the default thing later on, for example, after > checking whether it gets no performance drawback.) Just a detail about my previous patch. I didn't change the GPL license header from the original code, but I'm happy to actually release it under the LGPL (or even the BSD), since my resampler code is BSD anyway. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 6:48 ` Jean-Marc Valin @ 2007-02-20 10:45 ` Takashi Iwai 2007-02-20 11:54 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-02-20 10:45 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel At Tue, 20 Feb 2007 16:53:22 +1100, Jean-Marc Valin wrote: > > > Well, did you take a look at alsa-plugins/rate/rate_samplerate.c? > > That's _much_ easier than rewrting alsa-lib pcm_rate.c. This is > > another reason I recommended the external plugin as a first attempt. > > (And we can change the default thing later on, for example, after > > checking whether it gets no performance drawback.) > > Here's the plugin code. It's self-contained (includes my Public Parrot > Hack code) and it's based on on the libsamplerate plugin. I've tested it > and it seems to work right, but I'm not sure the code handles > "fractional samples" perfectly. Great. One concern in your code is that you use the same function names as in speex. This may result in namespace conflictions if alsa-lib is used together with speex. Please eitehr make these functions static and include from the main code, or rename functions with another prefix (e.g. snd_) to avoid confliction. > By that I mean that I don't see how the > plugin is supposed to handle the fact that the number of output samples > may vary even with the same number of input samples (e.g. downsampling > 1024 samples by a factor of 3 may produce either 341 or 342 samples). That's one part making alsa-lib rate plugin so complicated. Anyways, the resampling algorithm plugin doesn't take care much about it, so far. At Tue, 20 Feb 2007 17:48:06 +1100, Jean-Marc Valin wrote: > > Just a detail about my previous patch. I didn't change the GPL license > header from the original code, but I'm happy to actually release it > under the LGPL (or even the BSD), since my resampler code is BSD anyway. Yes, please change to any less-strict license as you with. The original libsamplerate plugin is released under GPL just because libsamplerate itself is GPL. I'm willing to change to LGPL if allowed. So, could you fix these issues and repost the patch, together with a certain description as a changelog to apply to the HG tree? BTW, we have another rate plugin using libavcodec (in another thread), and it's interesting to compare the performance of these. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 10:45 ` Takashi Iwai @ 2007-02-20 11:54 ` Jean-Marc Valin 2007-02-20 12:13 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-20 11:54 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel > One concern in your code is that you use the same function names as in > speex. This may result in namespace conflictions if alsa-lib is used > together with speex. Please eitehr make these functions static and > include from the main code, or rename functions with another prefix > (e.g. snd_) to avoid confliction. Right, I hadn't considered that yet. I think I prefer the static solution -- unless you're happy with linking directly with libspeex, which could be interesting if you're want to use the echo canceller and noise suppressor at some point. > That's one part making alsa-lib rate plugin so complicated. > Anyways, the resampling algorithm plugin doesn't take care much about > it, so far. Are you telling me people use the high-quality sinc in libsamplerate just to have the plugin drop samples once in a while? Can we just have a resampler that actually produces valid output once and for all? I guess it's another good reason to go directly with a non-plugin resampler. BTW, the way my resampler works is that you tell it the size of the input and output buffer and it tells you how many samples were read and how many were written (at least one of which is the same as the buffer size you passed). This should be flexible enough to put it in libasound without too much complications... 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 11:54 ` Jean-Marc Valin @ 2007-02-20 12:13 ` Takashi Iwai 2007-02-20 12:38 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-02-20 12:13 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel At Tue, 20 Feb 2007 22:54:48 +1100, Jean-Marc Valin wrote: > > > One concern in your code is that you use the same function names as in > > speex. This may result in namespace conflictions if alsa-lib is used > > together with speex. Please eitehr make these functions static and > > include from the main code, or rename functions with another prefix > > (e.g. snd_) to avoid confliction. > > Right, I hadn't considered that yet. I think I prefer the static > solution -- unless you're happy with linking directly with libspeex, > which could be interesting if you're want to use the echo canceller and > noise suppressor at some point. OK. > > That's one part making alsa-lib rate plugin so complicated. > > Anyways, the resampling algorithm plugin doesn't take care much about > > it, so far. > > Are you telling me people use the high-quality sinc in libsamplerate > just to have the plugin drop samples once in a while? Can we just have a > resampler that actually produces valid output once and for all? I guess > it's another good reason to go directly with a non-plugin resampler. No, I mean that there are many black magics in the alsa rate plugin to calculate the sampling buffer size constant so that the resampler side doesn't take care of it so much. And this has nothing to do with the fact whether it's an external plugin or not. I understand that you would like to put that to alsa-lib. But, it would reduce neither code size and complication. So let's prove the quality and performance first as a plugin, then replace the default one later. > BTW, the way my resampler works is that you tell it the size of the > input and output buffer and it tells you how many samples were read and > how many were written (at least one of which is the same as the buffer > size you passed). This should be flexible enough to put it in libasound > without too much complications... The actual problem isn't that. It's the restriction of "period" model that the current ALSA PCM is based on. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 12:13 ` Takashi Iwai @ 2007-02-20 12:38 ` Jean-Marc Valin 2007-02-20 21:50 ` Fernando Lopez-Lezcano 2007-02-20 22:07 ` James Courtier-Dutton 0 siblings, 2 replies; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-20 12:38 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel >>> That's one part making alsa-lib rate plugin so complicated. >>> Anyways, the resampling algorithm plugin doesn't take care much about >>> it, so far. >> Are you telling me people use the high-quality sinc in libsamplerate >> just to have the plugin drop samples once in a while? Can we just have a >> resampler that actually produces valid output once and for all? I guess >> it's another good reason to go directly with a non-plugin resampler. > > No, I mean that there are many black magics in the alsa rate plugin to > calculate the sampling buffer size constant so that the resampler side > doesn't take care of it so much. And this has nothing to do with the > fact whether it's an external plugin or not. OK, so plugin or not, how do you actually make sure you process all samples and not just the ones that are the most convenient? I can't believe I'm the only one here who actually cares about having correct audio coming in/out the soundcard. > I understand that you would like to put that to alsa-lib. But, it > would reduce neither code size and complication. So let's prove the > quality and performance first as a plugin, then replace the default > one later. Well, in terms of quality, Erik was kind enough to produce these graphs of a chirp being down-sampled from 96 kHz to 44.1 kHz: http://www.mega-nerd.com/tmp/speex_resampled_q10.png http://www.mega-nerd.com/tmp/speex_resampled_q5.png It should be pretty clear that the main limitation will be the 16-bit resolution (the aliasing lines are all below -120 dB). That, and of course the "discarding every N sample" problem, which is really bad. As far as performance goes, the code is really fast in the general case (faster than libsamplerate according to the tests I made) and even 4x faster than that when doing simple conversions (integer ratio of simple fraction). BTW, have you tested the plugin I sent yet? In the worst case, the default can be set to the lower quality resampling modes, which are still way better than linear resampling and yet take nearly no CPU. > The actual problem isn't that. It's the restriction of "period" model > that the current ALSA PCM is based on. And what's the solution to that one. What do you currently do with the linear resampler anyway? Drop samples again? 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 12:38 ` Jean-Marc Valin @ 2007-02-20 21:50 ` Fernando Lopez-Lezcano 2007-02-20 22:07 ` James Courtier-Dutton 1 sibling, 0 replies; 45+ messages in thread From: Fernando Lopez-Lezcano @ 2007-02-20 21:50 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: Takashi Iwai, alsa-devel On Tue, 2007-02-20 at 23:38 +1100, Jean-Marc Valin wrote: > >>> That's one part making alsa-lib rate plugin so complicated. > >>> Anyways, the resampling algorithm plugin doesn't take care much about > >>> it, so far. > >> Are you telling me people use the high-quality sinc in libsamplerate > >> just to have the plugin drop samples once in a while? Can we just have a > >> resampler that actually produces valid output once and for all? I guess > >> it's another good reason to go directly with a non-plugin resampler. > > > > No, I mean that there are many black magics in the alsa rate plugin to > > calculate the sampling buffer size constant so that the resampler side > > doesn't take care of it so much. And this has nothing to do with the > > fact whether it's an external plugin or not. > > OK, so plugin or not, how do you actually make sure you process all > samples and not just the ones that are the most convenient? I can't > believe I'm the only one here who actually cares about having correct > audio coming in/out the soundcard. You are not alone (at least two of us? :-) Linear interpolation works great as long as you don't have to listen to the output :-) Maybe nobody does... If somebody needs linear interp (slow processors?) they should be able to ask for it, but the default should be something more usable (and a better match to the "Advanced" part of the ALSA acronym). -- Fernando ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 12:38 ` Jean-Marc Valin 2007-02-20 21:50 ` Fernando Lopez-Lezcano @ 2007-02-20 22:07 ` James Courtier-Dutton 2007-02-20 22:45 ` Jean-Marc Valin ` (3 more replies) 1 sibling, 4 replies; 45+ messages in thread From: James Courtier-Dutton @ 2007-02-20 22:07 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: Takashi Iwai, alsa-devel Jean-Marc Valin wrote: >>>> That's one part making alsa-lib rate plugin so complicated. >>>> Anyways, the resampling algorithm plugin doesn't take care much about >>>> it, so far. >>> Are you telling me people use the high-quality sinc in libsamplerate >>> just to have the plugin drop samples once in a while? Can we just have a >>> resampler that actually produces valid output once and for all? I guess >>> it's another good reason to go directly with a non-plugin resampler. >> No, I mean that there are many black magics in the alsa rate plugin to >> calculate the sampling buffer size constant so that the resampler side >> doesn't take care of it so much. And this has nothing to do with the >> fact whether it's an external plugin or not. > > OK, so plugin or not, how do you actually make sure you process all > samples and not just the ones that are the most convenient? I can't > believe I'm the only one here who actually cares about having correct > audio coming in/out the soundcard. > >> I understand that you would like to put that to alsa-lib. But, it >> would reduce neither code size and complication. So let's prove the >> quality and performance first as a plugin, then replace the default >> one later. > > Well, in terms of quality, Erik was kind enough to produce these graphs > of a chirp being down-sampled from 96 kHz to 44.1 kHz: > http://www.mega-nerd.com/tmp/speex_resampled_q10.png > http://www.mega-nerd.com/tmp/speex_resampled_q5.png > It should be pretty clear that the main limitation will be the 16-bit > resolution (the aliasing lines are all below -120 dB). That, and of > course the "discarding every N sample" problem, which is really bad. > > As far as performance goes, the code is really fast in the general case > (faster than libsamplerate according to the tests I made) and even 4x > faster than that when doing simple conversions (integer ratio of simple > fraction). BTW, have you tested the plugin I sent yet? In the worst > case, the default can be set to the lower quality resampling modes, > which are still way better than linear resampling and yet take nearly no > CPU. > >> The actual problem isn't that. It's the restriction of "period" model >> that the current ALSA PCM is based on. > > And what's the solution to that one. What do you currently do with the > linear resampler anyway? Drop samples again? > > Jean-Marc > Unfortunately, the real problem with the alsa resamplers is not the quality of the algorithm. If it was just that, we would have fixed it ages ago. The real problem is related how the "period" model that ALSA currently uses functions. We need to implement new timers at the application rate, instead of trying to use the hardware rate. This would then require some extra buffer management. Currently, none of the ALSA developers have had enough time to implement the changes required. Here is a small example of what the problem really is: Hardware does 48000. We have the hardware period set at 1024, with 2 periods per buffer. The software application wishes to do 44100. So, the software application tries to set a period of 1024, with 2 periods per buffer. But, due to the restrictions of the current periods model, one can only do 44100/48000 * 1024 = 940.8 Now, we cannot use fractions of a period, so we return 940 as the max period size to the application. This results of a real application rate 44062.5. What we really need is for the application to get it's 44100, 1024 period size and 2 periods, and alsa-lib to provide the required abstraction to deliver 48000, 1024 period size and 2 periods to the hardware. So, as you can see, it is not an easy quick fix. James ------------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 22:07 ` James Courtier-Dutton @ 2007-02-20 22:45 ` Jean-Marc Valin 2007-02-21 2:10 ` Jean-Marc Valin ` (2 subsequent siblings) 3 siblings, 0 replies; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-20 22:45 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel > Unfortunately, the real problem with the alsa resamplers is not the > quality of the algorithm. If it was just that, we would have fixed it > ages ago. > The real problem is related how the "period" model that ALSA currently > uses functions. > We need to implement new timers at the application rate, instead of > trying to use the hardware rate. This would then require some extra > buffer management. Currently, none of the ALSA developers have had > enough time to implement the changes required. So in the nearly 10 years of ALSA existing, the problem has been known but nobody managed fix it (I realise it's hard)? > Here is a small example of what the problem really is: > Hardware does 48000. We have the hardware period set at 1024, with 2 > periods per buffer. > The software application wishes to do 44100. So, the software > application tries to set a period of 1024, with 2 periods per buffer. > But, due to the restrictions of the current periods model, one can only > do 44100/48000 * 1024 = 940.8 > Now, we cannot use fractions of a period, so we return 940 as the max > period size to the application. This results of a real application rate > 44062.5. > What we really need is for the application to get it's 44100, 1024 > period size and 2 periods, and alsa-lib to provide the required > abstraction to deliver 48000, 1024 period size and 2 periods to the > hardware. > > So, as you can see, it is not an easy quick fix. So until ALSA is fixed to do things properly, would it be possible to at least pass the information so that the resampler can actually use a ratio of 44062.5/48000 instead of attempting to do 44100/48000 and then dropping samples? Considering most soundcards have shitty clocks anyway, the problem may not be too bad (unless using really small period sizes of course). 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 22:07 ` James Courtier-Dutton 2007-02-20 22:45 ` Jean-Marc Valin @ 2007-02-21 2:10 ` Jean-Marc Valin 2007-02-21 9:18 ` Jean-Marc Valin 2007-02-21 14:48 ` Jean-Marc Valin 3 siblings, 0 replies; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-21 2:10 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel I've been having some problems with my plugin and trying to debug it, I've discovered what seems to be massive memory corruption in the rate converter plugin layer. It's actually not just with my plugin, but also with the libsamplerate plugin. For example, here's some of the stuff I found when running aplay in valgrind with the libsamplerate plugin (conversion was 4000 to 32000, which makes problems easier to trigger): ==21452== ==21452== Conditional jump or move depends on uninitialised value(s) ==21452== at 0x4482EF9: src_float_to_short_array (in /usr/lib/libsamplerate.so.0.1.1) ==21452== by 0x40EFB67: pcm_src_convert_s16 (rate_samplerate.c:126) ==21452== by 0x4081A0D: do_convert (pcm_rate.c:523) ==21452== by 0x4081DE9: snd_pcm_rate_commit_area (pcm_rate.c:541) ==21452== by 0x4081EDA: snd_pcm_rate_sync_playback_area (pcm_rate.c:862) ==21452== by 0x4081F86: snd_pcm_rate_mmap_commit (pcm_rate.c:1012) ==21452== by 0x406A529: snd_pcm_mmap_commit (pcm.c:6312) ==21452== by 0x4075779: snd_pcm_mmap_write_areas (pcm_mmap.c:123) ==21452== by 0x406A325: snd_pcm_write_areas (pcm.c:6499) ==21452== by 0x4074803: snd_pcm_mmap_writei (pcm_mmap.c:186) ==21452== by 0x4061275: snd_pcm_writei (pcm_local.h:401) ==21452== by 0x804C522: (within /usr/bin/aplay) ==21452== ==21452== Invalid write of size 1 ==21452== at 0x401E408: memcpy (mac_replace_strmem.c:394) ==21452== by 0x406AE6C: snd_pcm_area_copy (pcm.c:2549) ==21452== by 0x406B223: snd_pcm_areas_copy (pcm.c:2696) ==21452== by 0x4081D81: snd_pcm_rate_commit_area (pcm_rate.c:834) ==21452== by 0x408207E: snd_pcm_rate_drain (pcm_rate.c:1102) ==21452== by 0x4060F94: snd_pcm_drain (pcm.c:1092) ==21452== by 0x804E625: (within /usr/bin/aplay) ==21452== by 0x80506FB: (within /usr/bin/aplay) ==21452== by 0x4142EA1: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.6.so) ==21452== Address 0x42C82B8 is 0 bytes after a block of size 8,192 alloc'd ==21452== at 0x401C422: malloc (vg_replace_malloc.c:149) ==21452== by 0x4074DB1: snd_pcm_mmap (pcm_mmap.c:420) ==21452== by 0x406D79B: sndrv_pcm_hw_params (pcm_params.c:2357) ==21452== by 0x4075F7D: snd_pcm_generic_hw_params (pcm_generic.c:104) ==21452== by 0x406BA5E: snd_pcm_hw_params_slave (pcm_params.c:2240) ==21452== by 0x407F9DD: snd_pcm_rate_hw_params (pcm_rate.c:241) ==21452== by 0x406D58B: sndrv_pcm_hw_params (pcm_params.c:2316) ==21452== by 0x408605C: snd_pcm_plug_hw_params (pcm_plug.c:960) ==21452== by 0x406D58B: sndrv_pcm_hw_params (pcm_params.c:2316) ==21452== by 0x4060A24: snd_pcm_hw_params (pcm.c:825) ==21452== by 0x804B286: (within /usr/bin/aplay) ==21452== by 0x804DFE3: (within /usr/bin/aplay) I omitted the ioctl() warnings, which are probably just due to valgrind not knowing what ALSA's doing. In another simiar run, I got. ==21689== ==21689== Invalid free() / delete / delete[] ==21689== at 0x401CFCF: free (vg_replace_malloc.c:235) ==21689== by 0x448298D: src_delete (in /usr/lib/libsamplerate.so.0.1.1) ==21689== by 0x40EF99A: pcm_src_free (rate_samplerate.c:61) ==21689== by 0x407FDE7: snd_pcm_rate_hw_free (pcm_rate.c:338) ==21689== by 0x40607D1: snd_pcm_hw_free (pcm.c:848) ==21689== by 0x4084E77: snd_pcm_plug_hw_free (pcm_plug.c:976) ==21689== by 0x40607D1: snd_pcm_hw_free (pcm.c:848) ==21689== by 0x406A053: snd_pcm_close (pcm.c:698) ==21689== by 0x80506C4: (within /usr/bin/aplay) ==21689== by 0x4142EA1: __libc_start_main (in /lib/tls/i686/cmov/libc-2.3.6.so) ==21689== Address 0x20002 is not stack'd, malloc'd or (recently) free'd ==21689== I get similar problems with my resampler. And even when there's no apparent error, the playback sometimes just stops in the middle for no reason. I don't get these kinds of problems when using the cards's native rate or even when using crappy internal resampler. I definitely think this needs to be fixed before we get anything halfway decent working. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 22:07 ` James Courtier-Dutton 2007-02-20 22:45 ` Jean-Marc Valin 2007-02-21 2:10 ` Jean-Marc Valin @ 2007-02-21 9:18 ` Jean-Marc Valin 2007-02-22 11:38 ` Takashi Iwai 2007-02-21 14:48 ` Jean-Marc Valin 3 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-21 9:18 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel [-- Attachment #1: Type: text/plain, Size: 931 bytes --] > I've been having some problems with my plugin and trying to debug it, > I've discovered what seems to be massive memory corruption in the rate > converter plugin layer. It's actually not just with my plugin, but also > with the libsamplerate plugin. OK, so it turns out that the main bug wasn't in the plugin layer (though it could definitely be more robust), but in the original rate_samplerate plugin itself which had input_frames() and output_frames() actually implemented in reverse. So I'm attaching both a patch for rate_samplerate and a new version of my resampler plugin (now BSD-licensed). Both seem to work much better with the numerator and denominator in the right place. I still haven't changed the code to resolve the symbol conflict, but I'll do that soon. Can everyone give this a bit of testing? I hope we can soon get rid of linear resampling as the default resampling once and for all. Thanks, Jean-Marc [-- Attachment #2: samplerate.patch --] [-- Type: text/x-patch, Size: 614 bytes --] --- rate_samplerate.c.old 2007-02-21 19:49:05.000000000 +1100 +++ rate_samplerate.c 2007-02-21 19:49:16.000000000 +1100 @@ -38,7 +38,7 @@ struct rate_src *rate = obj; if (frames == 0) return 0; - return (snd_pcm_uframes_t)(frames * rate->ratio); + return (snd_pcm_uframes_t)(frames / rate->ratio); } static snd_pcm_uframes_t output_frames(void *obj, snd_pcm_uframes_t frames) @@ -46,7 +46,7 @@ struct rate_src *rate = obj; if (frames == 0) return 0; - return (snd_pcm_uframes_t)(frames / rate->ratio); + return (snd_pcm_uframes_t)(frames * rate->ratio); } static void pcm_src_free(void *obj) [-- Attachment #3: pph.tar.gz --] [-- Type: application/x-gzip, Size: 12297 bytes --] [-- Attachment #4: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #5: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-21 9:18 ` Jean-Marc Valin @ 2007-02-22 11:38 ` Takashi Iwai 2007-02-22 11:48 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-02-22 11:38 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Wed, 21 Feb 2007 20:18:10 +1100, Jean-Marc Valin wrote: > > > I've been having some problems with my plugin and trying to debug it, > > I've discovered what seems to be massive memory corruption in the rate > > converter plugin layer. It's actually not just with my plugin, but also > > with the libsamplerate plugin. > > OK, so it turns out that the main bug wasn't in the plugin layer (though > it could definitely be more robust), but in the original rate_samplerate > plugin itself which had input_frames() and output_frames() actually > implemented in reverse. Thanks, now committed to HG tree. > So I'm attaching both a patch for rate_samplerate and a new version of > my resampler plugin (now BSD-licensed). Both seem to work much better > with the numerator and denominator in the right place. I still haven't > changed the code to resolve the symbol conflict, but I'll do that soon. Regarding the license, LGPL would be suitable especailly if thinking about merging the code to alsa-lib tree later. Other codes in alsa-lib are all LGPL, so putting a BSD piece isn't fun. The license can be changed at merge time, though. Of course, if you prefer BSD, it's fine. We can keep it as is. > Can everyone give this a bit of testing? I hope we can soon get rid of > linear resampling as the default resampling once and for all. Looks working good as long as I've tested. Could you give a short document for this plugin, too (put in alsa-firmware/doc)? 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-22 11:38 ` Takashi Iwai @ 2007-02-22 11:48 ` Jean-Marc Valin 2007-02-22 12:07 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-22 11:48 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > Thanks, now committed to HG tree. Good, thanks. >> So I'm attaching both a patch for rate_samplerate and a new version of >> my resampler plugin (now BSD-licensed). Both seem to work much better >> with the numerator and denominator in the right place. I still haven't >> changed the code to resolve the symbol conflict, but I'll do that soon. > > Regarding the license, LGPL would be suitable especailly if thinking > about merging the code to alsa-lib tree later. Other codes in > alsa-lib are all LGPL, so putting a BSD piece isn't fun. The license > can be changed at merge time, though. > Of course, if you prefer BSD, it's fine. We can keep it as is. I don't mind at all relicensing to plugin to LGPL, since it's a part of ALSA anyway. The resampler itself is BSD and whenever possible, I'd really like to have any patch/fix to it available under the BSD. In any case, since any BSD code can be easily integrated into LGPL code, it shouldn't be a problem. >> Can everyone give this a bit of testing? I hope we can soon get rid of >> linear resampling as the default resampling once and for all. > > Looks working good as long as I've tested. > Could you give a short document for this plugin, too (put in > alsa-firmware/doc)? What kind of document do you want? I can't find anything about the other sample rate converters, so I'm not sure what it should look like. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-22 11:48 ` Jean-Marc Valin @ 2007-02-22 12:07 ` Takashi Iwai 2007-02-28 2:10 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-02-22 12:07 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Thu, 22 Feb 2007 22:48:57 +1100, Jean-Marc Valin wrote: > > > Thanks, now committed to HG tree. > > Good, thanks. > > >> So I'm attaching both a patch for rate_samplerate and a new version of > >> my resampler plugin (now BSD-licensed). Both seem to work much better > >> with the numerator and denominator in the right place. I still haven't > >> changed the code to resolve the symbol conflict, but I'll do that soon. > > > > Regarding the license, LGPL would be suitable especailly if thinking > > about merging the code to alsa-lib tree later. Other codes in > > alsa-lib are all LGPL, so putting a BSD piece isn't fun. The license > > can be changed at merge time, though. > > Of course, if you prefer BSD, it's fine. We can keep it as is. > > I don't mind at all relicensing to plugin to LGPL, since it's a part of > ALSA anyway. The resampler itself is BSD and whenever possible, I'd > really like to have any patch/fix to it available under the BSD. In any > case, since any BSD code can be easily integrated into LGPL code, it > shouldn't be a problem. Yes. I'll apply your current version to the HG tree now, then. > >> Can everyone give this a bit of testing? I hope we can soon get rid of > >> linear resampling as the default resampling once and for all. > > > > Looks working good as long as I've tested. > > Could you give a short document for this plugin, too (put in > > alsa-firmware/doc)? > > What kind of document do you want? I can't find anything about the other > sample rate converters, so I'm not sure what it should look like. A brief instruction how to set up would be enough. See alsa-plugins/doc/samplerate.txt, for example. Although it's planned to be merged in future, a documentation is always nice to have :) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-22 12:07 ` Takashi Iwai @ 2007-02-28 2:10 ` Jean-Marc Valin 2007-03-07 22:25 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-28 2:10 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton [-- Attachment #1: Type: text/plain, Size: 972 bytes --] > Yes. I'll apply your current version to the HG tree now, then. Thanks. Now, what are the requirements to have it enabled as the default resampler? >> What kind of document do you want? I can't find anything about the other >> sample rate converters, so I'm not sure what it should look like. > > A brief instruction how to set up would be enough. > See alsa-plugins/doc/samplerate.txt, for example. > > Although it's planned to be merged in future, a documentation is > always nice to have :) > OK, did a bit of search/replace on samplerate.txt and attached the result. As you can see, it's fairly similar. So far, I'm also including 3 levels of quality that match the libsamplerate levels, but I can change that depending on what people want. The Speex resampler offers quality settings that range from 0 to 10, so I can expose them all (is there a way to pass a quality parameter to the resampler instead of having to create lots of symbolic links?). Jean-Marc [-- Attachment #2: speexrate.txt --] [-- Type: text/plain, Size: 954 bytes --] Rate Converter Plugin Using Libsamplerate ========================================= The plugin in rate subdirectory is an external rate converter using the Speex resampler (aka Public Parrot Hack) by Jean-Marc Valin. You can use this rate converter plugin by defining a rate PCM with "converter" parameter, such as: pcm.my_rate { type rate slave.pcm "hw" converter "speexrate" } The plug plugin has also a similar field, "rate_converter". Or, more easily, define a global variable "defaults.pcm.rate_converter", which is used as the default converter type by plug and rate plugins: defaults.pcm.rate_converter "speexrate" Write the above in your ~/.asoundrc or /etc/asound.conf. The following converter types are available: - speexrate_best Use quality 10 (equivalent to SRC_SINC_BEST_QUALITY) - speexrate_medium Use quality 5 (equivalent to SRC_SINC_MEDIUM_QUALITY) - speexrate Use quality 3 (equivalent to SRC_SINC_FASTEST) [-- Attachment #3: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #4: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-28 2:10 ` Jean-Marc Valin @ 2007-03-07 22:25 ` Takashi Iwai 2007-03-08 0:59 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-07 22:25 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Wed, 28 Feb 2007 13:10:45 +1100, Jean-Marc Valin wrote: > > > Yes. I'll apply your current version to the HG tree now, then. > > Thanks. Now, what are the requirements to have it enabled as the default > resampler? Don't hurry up. We are still in a long rc phase :) Let's check with the latest 1.0.14rc3 and see the performance. Making it as default is so easy to add one line to /etc/alsa.conf (or ~/.asoundrc) as found in the documentation. > >> What kind of document do you want? I can't find anything about the other > >> sample rate converters, so I'm not sure what it should look like. > > > > A brief instruction how to set up would be enough. > > See alsa-plugins/doc/samplerate.txt, for example. > > > > Although it's planned to be merged in future, a documentation is > > always nice to have :) > > > > OK, did a bit of search/replace on samplerate.txt and attached the > result. As you can see, it's fairly similar. So far, I'm also including > 3 levels of quality that match the libsamplerate levels, but I can > change that depending on what people want. Thanks. I guess the title should be changed (I already took the fixed version on my local tree). > The Speex resampler offers > quality settings that range from 0 to 10, so I can expose them all (is > there a way to pass a quality parameter to the resampler instead of > having to create lots of symbolic links?). We can extend the rate plugin API so that the plugin code can refers the config parameters. But this would require an ABI extension / incompatibility. So I'd like to avoid this as much as possible. I don't think we need to expose all 11 ranges. Three should be enough, normally... 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-03-07 22:25 ` Takashi Iwai @ 2007-03-08 0:59 ` Jean-Marc Valin 2007-03-09 16:08 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-08 0:59 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > Don't hurry up. We are still in a long rc phase :) > Let's check with the latest 1.0.14rc3 and see the performance. > Making it as default is so easy to add one line to /etc/alsa.conf (or > ~/.asoundrc) as found in the documentation. OK, hopefully that can happen for 1.1.14... Did you actually test my plugin yet to see whether it works as expected? >> OK, did a bit of search/replace on samplerate.txt and attached the >> result. As you can see, it's fairly similar. So far, I'm also including >> 3 levels of quality that match the libsamplerate levels, but I can >> change that depending on what people want. > > Thanks. I guess the title should be changed (I already took the fixed > version on my local tree). Oops :-) >> The Speex resampler offers >> quality settings that range from 0 to 10, so I can expose them all (is >> there a way to pass a quality parameter to the resampler instead of >> having to create lots of symbolic links?). > > We can extend the rate plugin API so that the plugin code can refers > the config parameters. But this would require an ABI extension / > incompatibility. So I'd like to avoid this as much as possible. > > I don't think we need to expose all 11 ranges. Three should be > enough, normally... I think we can live with 3 settings, at least for now. The libsamplerate plugin had 5 settings, of which only 3 were useful (I used equivalent quality to those) -- the other 2 were zero-order hold and linear interpolation, which nobody in their right mind would want to use! One last thing, what happened to the other patch I sent for doing rounding-to-nearest (instead of rounding down) when doing sample format conversion? 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-03-08 0:59 ` Jean-Marc Valin @ 2007-03-09 16:08 ` Takashi Iwai 2007-03-20 13:22 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-09 16:08 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Thu, 08 Mar 2007 11:59:13 +1100, Jean-Marc Valin wrote: > > > Don't hurry up. We are still in a long rc phase :) > > Let's check with the latest 1.0.14rc3 and see the performance. > > Making it as default is so easy to add one line to /etc/alsa.conf (or > > ~/.asoundrc) as found in the documentation. > > OK, hopefully that can happen for 1.1.14... Did you actually test my > plugin yet to see whether it works as expected? Yes, it has been working well as far as I've tested. > >> OK, did a bit of search/replace on samplerate.txt and attached the > >> result. As you can see, it's fairly similar. So far, I'm also including > >> 3 levels of quality that match the libsamplerate levels, but I can > >> change that depending on what people want. > > > > Thanks. I guess the title should be changed (I already took the fixed > > version on my local tree). > > Oops :-) > > >> The Speex resampler offers > >> quality settings that range from 0 to 10, so I can expose them all (is > >> there a way to pass a quality parameter to the resampler instead of > >> having to create lots of symbolic links?). > > > > We can extend the rate plugin API so that the plugin code can refers > > the config parameters. But this would require an ABI extension / > > incompatibility. So I'd like to avoid this as much as possible. > > > > I don't think we need to expose all 11 ranges. Three should be > > enough, normally... > > I think we can live with 3 settings, at least for now. The libsamplerate > plugin had 5 settings, of which only 3 were useful (I used equivalent > quality to those) -- the other 2 were zero-order hold and linear > interpolation, which nobody in their right mind would want to use! > > One last thing, what happened to the other patch I sent for doing > rounding-to-nearest (instead of rounding down) when doing sample format > conversion? Sorry, forgotten until now. Applied with slight modification (introducing a macro) to HG tree now. Thanks for ping! 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-03-09 16:08 ` Takashi Iwai @ 2007-03-20 13:22 ` Jean-Marc Valin 2007-03-20 13:52 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-20 13:22 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton [-- Attachment #1: Type: text/plain, Size: 2313 bytes --] Hi, I'm attaching an updated version of my resampler plugin. It fixes a few minor issues and it adds support for fixed-point processing (just add -DFIXED_POINT to the build). Let me know if there's any problem. Jean-Marc Takashi Iwai a écrit : > At Thu, 08 Mar 2007 11:59:13 +1100, > Jean-Marc Valin wrote: >>> Don't hurry up. We are still in a long rc phase :) >>> Let's check with the latest 1.0.14rc3 and see the performance. >>> Making it as default is so easy to add one line to /etc/alsa.conf (or >>> ~/.asoundrc) as found in the documentation. >> OK, hopefully that can happen for 1.1.14... Did you actually test my >> plugin yet to see whether it works as expected? > > Yes, it has been working well as far as I've tested. > >>>> OK, did a bit of search/replace on samplerate.txt and attached the >>>> result. As you can see, it's fairly similar. So far, I'm also including >>>> 3 levels of quality that match the libsamplerate levels, but I can >>>> change that depending on what people want. >>> Thanks. I guess the title should be changed (I already took the fixed >>> version on my local tree). >> Oops :-) >> >>>> The Speex resampler offers >>>> quality settings that range from 0 to 10, so I can expose them all (is >>>> there a way to pass a quality parameter to the resampler instead of >>>> having to create lots of symbolic links?). >>> We can extend the rate plugin API so that the plugin code can refers >>> the config parameters. But this would require an ABI extension / >>> incompatibility. So I'd like to avoid this as much as possible. >>> >>> I don't think we need to expose all 11 ranges. Three should be >>> enough, normally... >> I think we can live with 3 settings, at least for now. The libsamplerate >> plugin had 5 settings, of which only 3 were useful (I used equivalent >> quality to those) -- the other 2 were zero-order hold and linear >> interpolation, which nobody in their right mind would want to use! >> >> One last thing, what happened to the other patch I sent for doing >> rounding-to-nearest (instead of rounding down) when doing sample format >> conversion? > > Sorry, forgotten until now. Applied with slight modification > (introducing a macro) to HG tree now. Thanks for ping! > > > Takashi > [-- Attachment #2: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #3: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-03-20 13:22 ` Jean-Marc Valin @ 2007-03-20 13:52 ` Takashi Iwai 2007-03-20 14:07 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-20 13:52 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Wed, 21 Mar 2007 00:22:28 +1100, Jean-Marc Valin wrote: > > Hi, > > I'm attaching an updated version of my resampler plugin. It fixes a few > minor issues and it adds support for fixed-point processing (just add > -DFIXED_POINT to the build). Let me know if there's any problem. Thanks. It would be helpful if you provide a diff rather a complete tarball at the next time. > diff -r 0bcf6f07c12c pph/rate_speexrate.c > --- a/pph/rate_speexrate.c Thu Mar 08 12:54:57 2007 +0100 > +++ b/pph/rate_speexrate.c Tue Mar 20 14:08:30 2007 +0100 > @@ -29,6 +29,7 @@ > */ > > #include <stdio.h> > +#include <samplerate.h> > #include <alsa/asoundlib.h> This requires additional check in configure. Why is this header needed now? > @@ -42,7 +43,7 @@ struct rate_src { > > static snd_pcm_uframes_t input_frames(void *obj, snd_pcm_uframes_t frames) > { > - int num, den; > + spx_uint32_t num, den; I don't see big merits to use its own types here... 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-03-20 13:52 ` Takashi Iwai @ 2007-03-20 14:07 ` Jean-Marc Valin 2007-03-20 14:19 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-20 14:07 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > Thanks. > It would be helpful if you provide a diff rather a complete tarball at > the next time. OK, I'll do that next time. >> diff -r 0bcf6f07c12c pph/rate_speexrate.c >> --- a/pph/rate_speexrate.c Thu Mar 08 12:54:57 2007 +0100 >> +++ b/pph/rate_speexrate.c Tue Mar 20 14:08:30 2007 +0100 >> @@ -29,6 +29,7 @@ >> */ >> >> #include <stdio.h> >> +#include <samplerate.h> >> #include <alsa/asoundlib.h> > > This requires additional check in configure. > Why is this header needed now? Oops, that's a mistake. There's no need for that include. Actually, it was also in the previous version I sent, so it's strange you're only noticing it now. >> @@ -42,7 +43,7 @@ struct rate_src { >> >> static snd_pcm_uframes_t input_frames(void *obj, snd_pcm_uframes_t frames) >> { >> - int num, den; >> + spx_uint32_t num, den; > > I don't see big merits to use its own types here... Well, I use that type because that's what is used in the API. And the reason I use it in the API is because this code is meant to work even on platforms with 16-bit integers (e.g. TI C5X DSPs) and no C99 compiler. If that's causing problem, I guess you could still use unsigned int with no problem... . 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-03-20 14:07 ` Jean-Marc Valin @ 2007-03-20 14:19 ` Takashi Iwai [not found] ` <4600539A.2070804@usherbrooke.ca> 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-20 14:19 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Wed, 21 Mar 2007 01:07:37 +1100, Jean-Marc Valin wrote: > > > Thanks. > > It would be helpful if you provide a diff rather a complete tarball at > > the next time. > > OK, I'll do that next time. > > >> diff -r 0bcf6f07c12c pph/rate_speexrate.c > >> --- a/pph/rate_speexrate.c Thu Mar 08 12:54:57 2007 +0100 > >> +++ b/pph/rate_speexrate.c Tue Mar 20 14:08:30 2007 +0100 > >> @@ -29,6 +29,7 @@ > >> */ > >> > >> #include <stdio.h> > >> +#include <samplerate.h> > >> #include <alsa/asoundlib.h> > > > > This requires additional check in configure. > > Why is this header needed now? > > Oops, that's a mistake. There's no need for that include. Actually, it > was also in the previous version I sent, so it's strange you're only > noticing it now. Heh, that's an advantage of reviewing a patch ;) > >> @@ -42,7 +43,7 @@ struct rate_src { > >> > >> static snd_pcm_uframes_t input_frames(void *obj, snd_pcm_uframes_t frames) > >> { > >> - int num, den; > >> + spx_uint32_t num, den; > > > > I don't see big merits to use its own types here... > > Well, I use that type because that's what is used in the API. And the > reason I use it in the API is because this code is meant to work even on > platforms with 16-bit integers (e.g. TI C5X DSPs) and no C99 compiler. > If that's causing problem, I guess you could still use unsigned int with > no problem... Don't worry, alsa-lib would be very unlikely ported to such an architecture. 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <4600539A.2070804@usherbrooke.ca>]
* Re: [Alsa-devel] Quality resampling code for libasound [not found] ` <4600539A.2070804@usherbrooke.ca> @ 2007-03-21 11:23 ` Takashi Iwai 2007-03-21 13:08 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 11:23 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Wed, 21 Mar 2007 08:35:22 +1100, Jean-Marc Valin wrote: > > >> Well, I use that type because that's what is used in the API. And the > >> reason I use it in the API is because this code is meant to work even on > >> platforms with 16-bit integers (e.g. TI C5X DSPs) and no C99 compiler. > >> If that's causing problem, I guess you could still use unsigned int with > >> no problem... > > > > Don't worry, alsa-lib would be very unlikely ported to such an > > architecture. > > Well, my code has to run on those architectures, and it's much simpler > if I don't need to change it for ALSA. Now if you don't want the > spx_uint32_t in the plugin code, then feel free to change that. OK, as long as it's in alsa-plugins repository, I basically don't care. But, for merging it to alsa-lib, I'd like to change the code very much (including coding-style unification). Anyway, I applied your latest codes to HG tree now (with the removal of samplerate.h). Thanks! Takashi ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 11:23 ` [Alsa-devel] " Takashi Iwai @ 2007-03-21 13:08 ` Jean-Marc Valin 2007-03-21 13:14 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-21 13:08 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > OK, as long as it's in alsa-plugins repository, I basically don't > care. But, for merging it to alsa-lib, I'd like to change the code > very much (including coding-style unification). Well, it's ultimately your call. For rate_speexrate.c, it really doesn't matter what happens because that's the only place it's used. When it comes to the resampler code itself, it depends on how you want to maintain it. I'll be maintaining it from the Speex tree, so it you want to change the style, you'll have to either "backport" improvements/fixes (e.g. optimisations) or do the style change again every time you sync. That is, unless you plan to do an alsa-specific fork of it. (I personally think the simplest way would be not modify the core resampler (resample.c and corresponding header files) and just sync with Speex once in a while. > Anyway, I applied your latest codes to HG tree now (with the removal > of samplerate.h). Thanks! Thanks. Jean-Marc ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 13:08 ` Jean-Marc Valin @ 2007-03-21 13:14 ` Takashi Iwai 2007-03-21 13:39 ` Jean-Marc Valin 2007-03-21 15:27 ` Rene Herman 0 siblings, 2 replies; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 13:14 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Thu, 22 Mar 2007 00:08:09 +1100, Jean-Marc Valin wrote: > > > OK, as long as it's in alsa-plugins repository, I basically don't > > care. But, for merging it to alsa-lib, I'd like to change the code > > very much (including coding-style unification). > > Well, it's ultimately your call. For rate_speexrate.c, it really doesn't > matter what happens because that's the only place it's used. When it > comes to the resampler code itself, it depends on how you want to > maintain it. I'll be maintaining it from the Speex tree, so it you want > to change the style, you'll have to either "backport" improvements/fixes > (e.g. optimisations) or do the style change again every time you sync. > That is, unless you plan to do an alsa-specific fork of it. (I > personally think the simplest way would be not modify the core resampler > (resample.c and corresponding header files) and just sync with Speex > once in a while. Yeah, this is an interesting question. We often see similar conflicts in the maintenance of linux kernel tree, too. The unified coding style gives clearly better readability of the whole tree. OTOH, if a code chunk is derived from another tree, it requires more additional backport effort. In the ideal situation, we may link to speex resampler as a dynamic library -- e.g. adding a configure option to let user choose the built-in or system-wide library resampler code. Does libspeex provide this code snip as exported? Takashi ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 13:14 ` Takashi Iwai @ 2007-03-21 13:39 ` Jean-Marc Valin 2007-03-21 13:59 ` Takashi Iwai 2007-03-21 15:27 ` Rene Herman 1 sibling, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-21 13:39 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > Yeah, this is an interesting question. We often see similar conflicts > in the maintenance of linux kernel tree, too. The unified coding > style gives clearly better readability of the whole tree. OTOH, if a > code chunk is derived from another tree, it requires more additional > backport effort. I think the main question is: do you plan on making many alsa-specific changes to that code? resampler.c is pretty much as close as you get to pure signal processing code (no "system" stuff), so I don't think many people will actually want to mess with it and any improvements might as well be merged in Speex first to be tested for a while. Of course, if the coding rules are simple, an other approach could be to automatically re-indent the code when syncing. Of course, it still means you need to keep the same code as Speex has. In any case, I'd recommend not forking that code too early because some of the planned improvements (e.g. SSE optimisations) could be a pain to backport. > In the ideal situation, we may link to speex resampler as a dynamic > library -- e.g. adding a configure option to let user choose the > built-in or system-wide library resampler code. Does libspeex provide > this code snip as exported? Not sure I understand what you mean here. If you're asking whether the symbols for the resampler are exported in the shared library, then the answer is yes -- though the resampler is only in the svn version of Speex for now. The first release to include it will be 1.2beta2, which I'm planning to release in a few weeks. Jean-Marc ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 13:39 ` Jean-Marc Valin @ 2007-03-21 13:59 ` Takashi Iwai 2007-03-21 14:19 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 13:59 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Thu, 22 Mar 2007 00:39:44 +1100, Jean-Marc Valin wrote: > > > Yeah, this is an interesting question. We often see similar conflicts > > in the maintenance of linux kernel tree, too. The unified coding > > style gives clearly better readability of the whole tree. OTOH, if a > > code chunk is derived from another tree, it requires more additional > > backport effort. > > I think the main question is: do you plan on making many alsa-specific > changes to that code? Yes (not alsa-specific but less speex-specific), once if it's merged to alsa-lib tree. (The code can't be applied to the tree as it is, BTW, because it must be LGPL, as we discussed...) > resampler.c is pretty much as close as you get to > pure signal processing code (no "system" stuff), so I don't think many > people will actually want to mess with it and any improvements might as > well be merged in Speex first to be tested for a while. Of course, if > the coding rules are simple, an other approach could be to automatically > re-indent the code when syncing. Of course, it still means you need to > keep the same code as Speex has. In any case, I'd recommend not forking > that code too early because some of the planned improvements (e.g. SSE > optimisations) could be a pain to backport. Yes, but if the code is in another tree, it's actually a fork. Having codes that may be frequently changed in multiple places is already a risky action from the maintenance POV, regardless of the coding style. That's what I'd like to avoid. > > In the ideal situation, we may link to speex resampler as a dynamic > > library -- e.g. adding a configure option to let user choose the > > built-in or system-wide library resampler code. Does libspeex provide > > this code snip as exported? > > Not sure I understand what you mean here. If you're asking whether the > symbols for the resampler are exported in the shared library, then the > answer is yes -- though the resampler is only in the svn version of > Speex for now. The first release to include it will be 1.2beta2, which > I'm planning to release in a few weeks. Ah, OK. I asked it because I couldn't find symbols in my libspeex binary. Takashi ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 13:59 ` Takashi Iwai @ 2007-03-21 14:19 ` Jean-Marc Valin 2007-03-21 14:53 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-21 14:19 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > Yes (not alsa-specific but less speex-specific), Outside of the spx_int* types, what are the speex-specific bits that bother you? > once if it's merged > to alsa-lib tree. (The code can't be applied to the tree as it is, > BTW, because it must be LGPL, as we discussed...) Is a COPYING file OK or do you need headers (in which case, what's the smallest header that can be added?)? > Yes, but if the code is in another tree, it's actually a fork. > Having codes that may be frequently changed in multiple places is > already a risky action from the maintenance POV, regardless of the > coding style. That's what I'd like to avoid. Then the solution would be to just copy from the Speex tree once in a while and get the fixes there first. You can always have an automated formatting tool that you run after importing a new version. Overall, I really see no reason why you'd want to modify the resampler in the first place -- other than fixing bugs, which should go in the Speex tree anyway. Jean-Marc ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 14:19 ` Jean-Marc Valin @ 2007-03-21 14:53 ` Takashi Iwai 2007-03-21 15:17 ` Jean-Marc Valin 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 14:53 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Thu, 22 Mar 2007 01:19:18 +1100, Jean-Marc Valin wrote: > > > Yes (not alsa-specific but less speex-specific), > > Outside of the spx_int* types, what are the speex-specific bits that > bother you? There are lots of macros in arch.h and speex_resampler.h, which try to absorb the difference from non-C99 and non-LP32 platforms. BTW, I'm not against these codes at all in general. But, between speex and alsa-lib, the target is simply different. Hence the code should be written in a different manner accordingly. > > once if it's merged > > to alsa-lib tree. (The code can't be applied to the tree as it is, > > BTW, because it must be LGPL, as we discussed...) > > Is a COPYING file OK or do you need headers (in which case, what's the > smallest header that can be added?)? Each file in pph/* contains the BSD headers, so we have to change them anyway. > > Yes, but if the code is in another tree, it's actually a fork. > > Having codes that may be frequently changed in multiple places is > > already a risky action from the maintenance POV, regardless of the > > coding style. That's what I'd like to avoid. > > Then the solution would be to just copy from the Speex tree once in a > while and get the fixes there first. You can always have an automated > formatting tool that you run after importing a new version. Overall, I > really see no reason why you'd want to modify the resampler in the first > place -- other than fixing bugs, which should go in the Speex tree anyway. IMO, it never worked well, looking at history. For example, you can find a piece of zlib code everywhere, but they are not synchronized and well bugfixed (especially thinking of many security fixes in zlib). The only working solution for synchronized source management is to use the shared library. Takashi ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 14:53 ` Takashi Iwai @ 2007-03-21 15:17 ` Jean-Marc Valin 2007-03-21 15:43 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-21 15:17 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton > There are lots of macros in arch.h and speex_resampler.h, which try to > absorb the difference from non-C99 and non-LP32 platforms. Actually, most of the stuff in arch.h is designed to abstract the operators so they can be defined for fixed-point or floating point (e.g. spx_word32_t is defined either as float or as int depending on how you compile). There's nothing about non-C99 stuff and the only non-LP32 stuff are the few spx_int* types. > BTW, I'm not against these codes at all in general. But, between > speex and alsa-lib, the target is simply different. Hence the code > should be written in a different manner accordingly. But is it worth increasing the maintenance overhead for code that may never be modified directly in alsa. Note that I'm not talking about the plugin code that uses the resampler here. > Each file in pph/* contains the BSD headers, so we have to change them > anyway. Can't we just add a "Oh and BTW, you can also use it under the LGPL" right after the BSD header. This is something I'd be willing to do in the Speex tree. Apply a new license when syncing code seems like a bad idea to me. > IMO, it never worked well, looking at history. For example, you can > find a piece of zlib code everywhere, but they are not synchronized > and well bugfixed (especially thinking of many security fixes in > zlib). Well, I can't really think of something better for now. > The only working solution for synchronized source management is to use > the shared library. You could do that too, but it means you'll be forcing libspeex > 1.2beta2 onto all distributions. I don't mind because it should be quite a good release, but maybe some will object. I'd suggest just doing a copy in the short term and then move to the shared library when distros have it. Jean-Marc ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 15:17 ` Jean-Marc Valin @ 2007-03-21 15:43 ` Takashi Iwai 0 siblings, 0 replies; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 15:43 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton At Thu, 22 Mar 2007 02:17:56 +1100, Jean-Marc Valin wrote: > > > There are lots of macros in arch.h and speex_resampler.h, which try to > > absorb the difference from non-C99 and non-LP32 platforms. > > Actually, most of the stuff in arch.h is designed to abstract the > operators so they can be defined for fixed-point or floating point (e.g. > spx_word32_t is defined either as float or as int depending on how you > compile). There's nothing about non-C99 stuff and the only non-LP32 > stuff are the few spx_int* types. OK. > > BTW, I'm not against these codes at all in general. But, between > > speex and alsa-lib, the target is simply different. Hence the code > > should be written in a different manner accordingly. > > But is it worth increasing the maintenance overhead for code that may > never be modified directly in alsa. Note that I'm not talking about the > plugin code that uses the resampler here. Well, this arises another question: If the code is not allowed to modify, why to bother to include the code in the tree? Why not use a shared library? > > Each file in pph/* contains the BSD headers, so we have to change them > > anyway. > > Can't we just add a "Oh and BTW, you can also use it under the LGPL" > right after the BSD header. This is something I'd be willing to do in > the Speex tree. Apply a new license when syncing code seems like a bad > idea to me. I personally don't like the dual license. It can't work seriously if someone changes/forks the code. > > IMO, it never worked well, looking at history. For example, you can > > find a piece of zlib code everywhere, but they are not synchronized > > and well bugfixed (especially thinking of many security fixes in > > zlib). > > Well, I can't really think of something better for now. > > > The only working solution for synchronized source management is to use > > the shared library. > > You could do that too, but it means you'll be forcing libspeex > > 1.2beta2 onto all distributions. I don't mind because it should be quite > a good release, but maybe some will object. I'd suggest just doing a > copy in the short term and then move to the shared library when distros > have it. I feel the easiest way for both of us is just to keep alsa-plugins as it is. (Or, even better, we can modify alsa-plugin configure script to detect libspeex, too. This will decrease the maintenance const.) Then, change alsa-lib rate plugin to look up the list of plugins, and put "speexrate" to the top of it and "linear" to the bottom in the default configuration, so that speex resampler can be used (if installed) and the built-in linear plugin can be safely used as a fallback. Takashi ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 13:14 ` Takashi Iwai 2007-03-21 13:39 ` Jean-Marc Valin @ 2007-03-21 15:27 ` Rene Herman 2007-03-21 15:34 ` Jean-Marc Valin 1 sibling, 1 reply; 45+ messages in thread From: Rene Herman @ 2007-03-21 15:27 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, James Courtier-Dutton, Jean-Marc Valin On 03/21/2007 02:14 PM, Takashi Iwai wrote: > In the ideal situation, we may link to speex resampler as a dynamic > library -- e.g. adding a configure option to let user choose the > built-in or system-wide library resampler code. Does libspeex > provide this code snip as exported? There's one problem with that solution though; people generally don't compile and install alsa-lib themselves these days and since distributions may not be too keen on having their alsa-lib package dependent on their speex package they might just compile with the builtin code. Users of these distributions would then have to be fairly familiar with alsa to know they could improve sound by recompiling alsa-lib against the speex libraries, but given that it's (also) dirt cheap soundcards that need the resampling, their users aren't too likely to _be_ fairly familiar. They'd just observe (still) that their sound is "much better on windows". If the standard code is as lousy as I've read in this thread, keeping it as default is probably not the best thing. Rene. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 15:27 ` Rene Herman @ 2007-03-21 15:34 ` Jean-Marc Valin 2007-03-21 16:38 ` Rene Herman 0 siblings, 1 reply; 45+ messages in thread From: Jean-Marc Valin @ 2007-03-21 15:34 UTC (permalink / raw) To: Rene Herman; +Cc: alsa-devel, James Courtier-Dutton > Users of these distributions would then have to be fairly familiar with > alsa to know they could improve sound by recompiling alsa-lib against > the speex libraries, but given that it's (also) dirt cheap soundcards > that need the resampling, their users aren't too likely to _be_ fairly > familiar. They'd just observe (still) that their sound is "much better > on windows". Oh, I meant using a copy of the pph code in the mean time, not the current linear interpolation resampler. > If the standard code is as lousy as I've read in this thread, keeping it > as default is probably not the best thing. It's worse than you think :-) Try playing an 8 kHz file to a soundcard that only does 44.1/48. It's just horrible. Jean-Marc ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 15:34 ` Jean-Marc Valin @ 2007-03-21 16:38 ` Rene Herman 2007-03-21 16:57 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Rene Herman @ 2007-03-21 16:38 UTC (permalink / raw) To: Jean-Marc Valin; +Cc: alsa-devel, James Courtier-Dutton On 03/21/2007 04:34 PM, Jean-Marc Valin wrote: >> Users of these distributions would then have to be fairly familiar with >> alsa to know they could improve sound by recompiling alsa-lib against >> the speex libraries, but given that it's (also) dirt cheap soundcards >> that need the resampling, their users aren't too likely to _be_ fairly >> familiar. They'd just observe (still) that their sound is "much better >> on windows". > > Oh, I meant using a copy of the pph code in the mean time, not the > current linear interpolation resampler. Mmm, I believe Takashi Iwai was though. If I interpreted him correctly he proposed to optionally link libasound against libspeex (libresample?) if so ./config-ured and found at alsa-lib compile time but to keep using the current resampler when not. Given the idea that distributions probably don't want their alsa-lib package dependent on their speex package (alsa-lib is right above the kernel and mandatory on any Linux system wanting to do anything with sound while speex is significantly higher up on the chain) I worried this would mean your code wouldn't be used in practice. >> If the standard code is as lousy as I've read in this thread, >> keeping it as default is probably not the best thing. > > It's worse than you think :-) Try playing an 8 kHz file to a > soundcard that only does 44.1/48. It's just horrible. Trouble is that I don't have a soundcard that can only do 44.1/48. I'll go hack up a driver to pretend I do though and try. Have a nice 8 kHz file I can try with? :) Rene. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 16:38 ` Rene Herman @ 2007-03-21 16:57 ` Takashi Iwai 2007-03-21 17:24 ` Takashi Iwai 0 siblings, 1 reply; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 16:57 UTC (permalink / raw) To: Rene Herman; +Cc: alsa-devel, James Courtier-Dutton, Jean-Marc Valin At Wed, 21 Mar 2007 17:38:21 +0100, Rene Herman wrote: > > On 03/21/2007 04:34 PM, Jean-Marc Valin wrote: > > >> Users of these distributions would then have to be fairly familiar with > >> alsa to know they could improve sound by recompiling alsa-lib against > >> the speex libraries, but given that it's (also) dirt cheap soundcards > >> that need the resampling, their users aren't too likely to _be_ fairly > >> familiar. They'd just observe (still) that their sound is "much better > >> on windows". > > > > Oh, I meant using a copy of the pph code in the mean time, not the > > current linear interpolation resampler. > > Mmm, I believe Takashi Iwai was though. If I interpreted him correctly > he proposed to optionally link libasound against libspeex (libresample?) > if so ./config-ured and found at alsa-lib compile time but to keep using > the current resampler when not. > > Given the idea that distributions probably don't want their alsa-lib > package dependent on their speex package (alsa-lib is right above the > kernel and mandatory on any Linux system wanting to do anything with > sound while speex is significantly higher up on the chain) I worried > this would mean your code wouldn't be used in practice. Well, my (latest) prpoposal is: - keep speex resampler in alsa-plugins tree - installing this plugin automatically enables it as the default rate converter without touching any configuration The second part is missing right now. In this way, distro simply needs to build alsa-plugins-pph package and install it as one of default packages. alsa-lib tree could be still built without speex. So, the package dependency is no longer big problem. Takashi ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [Alsa-devel] Quality resampling code for libasound 2007-03-21 16:57 ` Takashi Iwai @ 2007-03-21 17:24 ` Takashi Iwai 0 siblings, 0 replies; 45+ messages in thread From: Takashi Iwai @ 2007-03-21 17:24 UTC (permalink / raw) To: Rene Herman; +Cc: alsa-devel, Jean-Marc Valin, James Courtier-Dutton At Wed, 21 Mar 2007 17:57:38 +0100, I wrote: > > At Wed, 21 Mar 2007 17:38:21 +0100, > Rene Herman wrote: > > > > On 03/21/2007 04:34 PM, Jean-Marc Valin wrote: > > > > >> Users of these distributions would then have to be fairly familiar with > > >> alsa to know they could improve sound by recompiling alsa-lib against > > >> the speex libraries, but given that it's (also) dirt cheap soundcards > > >> that need the resampling, their users aren't too likely to _be_ fairly > > >> familiar. They'd just observe (still) that their sound is "much better > > >> on windows". > > > > > > Oh, I meant using a copy of the pph code in the mean time, not the > > > current linear interpolation resampler. > > > > Mmm, I believe Takashi Iwai was though. If I interpreted him correctly > > he proposed to optionally link libasound against libspeex (libresample?) > > if so ./config-ured and found at alsa-lib compile time but to keep using > > the current resampler when not. > > > > Given the idea that distributions probably don't want their alsa-lib > > package dependent on their speex package (alsa-lib is right above the > > kernel and mandatory on any Linux system wanting to do anything with > > sound while speex is significantly higher up on the chain) I worried > > this would mean your code wouldn't be used in practice. > > Well, my (latest) prpoposal is: > > - keep speex resampler in alsa-plugins tree > - installing this plugin automatically enables it as the default rate > converter without touching any configuration > > The second part is missing right now. ... and the patch below supports it. With this patch, you can set the list of multiple default PCM rate converters. For example, defaults.pcm.rate_converter [ "speexrate" "samplerate" "linear" ] will look for speex plugin, then libsamplerate plugin, lastly it will take the built-in linear converter as a fallback. So, we can define this safely in the default alsa.conf file. Takashi diff -r c40d95b55851 include/pcm_plugin.h --- a/include/pcm_plugin.h Wed Mar 21 12:21:38 2007 +0100 +++ b/include/pcm_plugin.h Wed Mar 21 17:12:30 2007 +0100 @@ -156,7 +156,8 @@ int _snd_pcm_route_open(snd_pcm_t **pcmp * Rate plugin for linear formats */ int snd_pcm_rate_open(snd_pcm_t **pcmp, const char *name, - snd_pcm_format_t sformat, unsigned int srate, const char *converter, + snd_pcm_format_t sformat, unsigned int srate, + const snd_config_t *converter, snd_pcm_t *slave, int close_slave); int _snd_pcm_rate_open(snd_pcm_t **pcmp, const char *name, snd_config_t *root, snd_config_t *conf, diff -r c40d95b55851 src/pcm/pcm_local.h --- a/src/pcm/pcm_local.h Wed Mar 21 12:21:38 2007 +0100 +++ b/src/pcm/pcm_local.h Wed Mar 21 17:11:34 2007 +0100 @@ -756,7 +756,7 @@ int snd_pcm_hw_open_fd(snd_pcm_t **pcmp, int snd_pcm_wait_nocheck(snd_pcm_t *pcm, int timeout); -const char *snd_pcm_rate_get_default_converter(snd_config_t *root); +const snd_config_t *snd_pcm_rate_get_default_converter(snd_config_t *root); #define SND_PCM_HW_PARBIT_ACCESS (1U << SND_PCM_HW_PARAM_ACCESS) #define SND_PCM_HW_PARBIT_FORMAT (1U << SND_PCM_HW_PARAM_FORMAT) diff -r c40d95b55851 src/pcm/pcm_plug.c --- a/src/pcm/pcm_plug.c Wed Mar 21 12:21:38 2007 +0100 +++ b/src/pcm/pcm_plug.c Wed Mar 21 18:11:36 2007 +0100 @@ -50,7 +50,7 @@ typedef struct { snd_pcm_format_t sformat; int schannels; int srate; - const char *rate_converter; + const snd_config_t *rate_converter; enum snd_pcm_plug_route_policy route_policy; snd_pcm_route_ttable_entry_t *ttable; int ttable_ok, ttable_last; @@ -1015,7 +1015,7 @@ int snd_pcm_plug_open(snd_pcm_t **pcmp, int snd_pcm_plug_open(snd_pcm_t **pcmp, const char *name, snd_pcm_format_t sformat, int schannels, int srate, - const char *rate_converter, + const snd_config_t *rate_converter, enum snd_pcm_plug_route_policy route_policy, snd_pcm_route_ttable_entry_t *ttable, unsigned int tt_ssize, @@ -1133,7 +1133,7 @@ int _snd_pcm_plug_open(snd_pcm_t **pcmp, unsigned int cused, sused; snd_pcm_format_t sformat = SND_PCM_FORMAT_UNKNOWN; int schannels = -1, srate = -1; - const char *rate_converter = NULL; + const snd_config_t *rate_converter = NULL; snd_config_for_each(i, next, conf) { snd_config_t *n = snd_config_iterator_entry(i); @@ -1177,12 +1177,7 @@ int _snd_pcm_plug_open(snd_pcm_t **pcmp, #endif #ifdef BUILD_PCM_PLUGIN_RATE if (strcmp(id, "rate_converter") == 0) { - const char *str; - if ((err = snd_config_get_string(n, &str)) < 0) { - SNDERR("Invalid type for %s", id); - return -EINVAL; - } - rate_converter = str; + rate_converter = n; continue; } #endif diff -r c40d95b55851 src/pcm/pcm_rate.c --- a/src/pcm/pcm_rate.c Wed Mar 21 12:21:38 2007 +0100 +++ b/src/pcm/pcm_rate.c Wed Mar 21 18:18:35 2007 +0100 @@ -1254,17 +1254,44 @@ static snd_pcm_ops_t snd_pcm_rate_ops = * \param root Root configuration node * \retval A const string if found, or NULL */ -const char *snd_pcm_rate_get_default_converter(snd_config_t *root) +const snd_config_t *snd_pcm_rate_get_default_converter(snd_config_t *root) { snd_config_t *n; /* look for default definition */ - if (snd_config_search(root, "defaults.pcm.rate_converter", &n) >= 0) { - const char *str; - if (snd_config_get_string(n, &str) >= 0) - return str; - } + if (snd_config_search(root, "defaults.pcm.rate_converter", &n) >= 0) + return n; return NULL; } + +#ifdef PIC +static int rate_open_func(snd_pcm_rate_t *rate, const char *type) +{ + char open_name[64]; + snd_pcm_rate_open_func_t open_func; + + snprintf(open_name, sizeof(open_name), "_snd_pcm_rate_%s_open", type); + open_func = snd_dlobj_cache_lookup(open_name); + if (!open_func) { + void *h; + char lib_name[128], *lib = NULL; + if (strcmp(type, "linear")) { + snprintf(lib_name, sizeof(lib_name), + "%s/libasound_module_rate_%s.so", PKGLIBDIR, type); + lib = lib_name; + } + h = snd_dlopen(lib, RTLD_NOW); + if (!h) + return -ENOENT; + open_func = dlsym(h, open_name); + if (!open_func) { + snd_dlclose(h); + return -ENOENT; + } + snd_dlobj_cache_add(open_name, h, open_func); + } + return open_func(SND_PCM_RATE_PLUGIN_VERSION, &rate->obj, &rate->ops); +} +#endif /** * \brief Creates a new rate PCM @@ -1280,15 +1307,17 @@ const char *snd_pcm_rate_get_default_con * of compatibility reasons. The prototype might be freely * changed in future. */ -int snd_pcm_rate_open(snd_pcm_t **pcmp, const char *name, snd_pcm_format_t sformat, - unsigned int srate, const char *type, snd_pcm_t *slave, int close_slave) +int snd_pcm_rate_open(snd_pcm_t **pcmp, const char *name, + snd_pcm_format_t sformat, unsigned int srate, + const snd_config_t *converter, + snd_pcm_t *slave, int close_slave) { snd_pcm_t *pcm; snd_pcm_rate_t *rate; - snd_pcm_rate_open_func_t open_func; - char open_name[64]; + const char *type; int err; #ifndef PIC + snd_pcm_rate_open_func_t open_func; extern int SND_PCM_RATE_PLUGIN_ENTRY(linear) (unsigned int version, void **objp, snd_pcm_rate_ops_t *ops); #endif @@ -1306,49 +1335,47 @@ int snd_pcm_rate_open(snd_pcm_t **pcmp, rate->sformat = sformat; snd_atomic_write_init(&rate->watom); - if (! type || ! *type) - type = "linear"; - -#ifdef PIC - snprintf(open_name, sizeof(open_name), "_snd_pcm_rate_%s_open", type); - open_func = snd_dlobj_cache_lookup(open_name); - if (! open_func) { - void *h; - char lib_name[128], *lib = NULL; - if (strcmp(type, "linear")) { - snprintf(lib_name, sizeof(lib_name), - "%s/libasound_module_rate_%s.so", PKGLIBDIR, type); - lib = lib_name; - } - h = snd_dlopen(lib, RTLD_NOW); - if (! h) { - SNDERR("Cannot open library for type %s", type); - free(rate); - return -ENOENT; - } - open_func = dlsym(h, open_name); - if (! open_func) { - SNDERR("Cannot find function %s", open_name); - snd_dlclose(h); - free(rate); - return -ENOENT; - } - snd_dlobj_cache_add(open_name, h, open_func); - } -#else - open_func = SND_PCM_RATE_PLUGIN_ENTRY(linear); -#endif - err = snd_pcm_new(&pcm, SND_PCM_TYPE_RATE, name, slave->stream, slave->mode); if (err < 0) { free(rate); return err; } + +#ifdef PIC + err = -ENOENT; + if (!converter) + err = rate_open_func(rate, "linear"); + else if (!snd_config_get_string(converter, &type)) + err = rate_open_func(rate, type); + else if (snd_config_get_type(converter) == SND_CONFIG_TYPE_COMPOUND) { + snd_config_iterator_t i, next; + snd_config_for_each(i, next, converter) { + snd_config_t *n = snd_config_iterator_entry(i); + if (snd_config_get_string(n, &type) < 0) + break; + err = rate_open_func(rate, type); + if (!err) + break; + } + } else { + SNDERR("Invalid type for rate converter"); + snd_pcm_close(pcm); + return -EINVAL; + } + if (err < 0) { + SNDERR("Cannot find rate converter"); + snd_pcm_close(pcm); + return -ENOENT; + } +#else + open_func = SND_PCM_RATE_PLUGIN_ENTRY(linear); err = open_func(SND_PCM_RATE_PLUGIN_VERSION, &rate->obj, &rate->ops); if (err < 0) { snd_pcm_close(pcm); return err; } +#endif + if (! rate->ops.init || ! (rate->ops.convert || rate->ops.convert_s16) || ! rate->ops.input_frames || ! rate->ops.output_frames) { SNDERR("Inproper rate plugin %s initialization", type); @@ -1424,7 +1451,7 @@ int _snd_pcm_rate_open(snd_pcm_t **pcmp, snd_config_t *slave = NULL, *sconf; snd_pcm_format_t sformat = SND_PCM_FORMAT_UNKNOWN; int srate = -1; - const char *type = NULL; + const snd_config_t *converter = NULL; snd_config_for_each(i, next, conf) { snd_config_t *n = snd_config_iterator_entry(i); @@ -1438,12 +1465,7 @@ int _snd_pcm_rate_open(snd_pcm_t **pcmp, continue; } if (strcmp(id, "converter") == 0) { - const char *str; - if ((err = snd_config_get_string(n, &str)) < 0) { - SNDERR("invalid converter string"); - return -EINVAL; - } - type = str; + converter = n; continue; } SNDERR("Unknown field %s", id); @@ -1470,7 +1492,7 @@ int _snd_pcm_rate_open(snd_pcm_t **pcmp, if (err < 0) return err; err = snd_pcm_rate_open(pcmp, name, sformat, (unsigned int) srate, - type, spcm, 1); + converter, spcm, 1); if (err < 0) snd_pcm_close(spcm); return err; ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-20 22:07 ` James Courtier-Dutton ` (2 preceding siblings ...) 2007-02-21 9:18 ` Jean-Marc Valin @ 2007-02-21 14:48 ` Jean-Marc Valin 3 siblings, 0 replies; 45+ messages in thread From: Jean-Marc Valin @ 2007-02-21 14:48 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: Takashi Iwai, alsa-devel [-- Attachment #1: Type: text/plain, Size: 317 bytes --] Hi everyone, Attached is the plugin in a state where it can actually be merged. The symbol clash problem is fixed and there's no other outstanding issue that I'm aware of. The default (quality 3) has pretty decent quality and the CPU usage is quite low (~2% for 8 kHz to 44.1 kHz on my laptop). Cheers, Jean-Marc [-- Attachment #2: pph.tar.gz --] [-- Type: application/x-gzip, Size: 12105 bytes --] [-- Attachment #3: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #4: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 12:54 ` Jean-Marc Valin 2007-02-19 13:10 ` Takashi Iwai @ 2007-02-19 13:11 ` Prakash Punnoor 2007-02-19 13:36 ` Adam Tlałka 1 sibling, 1 reply; 45+ messages in thread From: Prakash Punnoor @ 2007-02-19 13:11 UTC (permalink / raw) To: alsa-devel [-- Attachment #1.1: Type: text/plain, Size: 1154 bytes --] Am Montag 19 Februar 2007 schrieb Jean-Marc Valin: > >> 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. ACK (scnr) -- (°= =°) //\ Prakash Punnoor /\\ V_/ \_V [-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --] [-- Attachment #2: Type: text/plain, Size: 345 bytes --] ------------------------------------------------------------------------- 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 [-- Attachment #3: Type: text/plain, Size: 161 bytes --] _______________________________________________ Alsa-devel mailing list Alsa-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Quality resampling code for libasound 2007-02-19 13:11 ` Prakash Punnoor @ 2007-02-19 13:36 ` Adam Tlałka 0 siblings, 0 replies; 45+ messages in thread From: Adam Tlałka @ 2007-02-19 13:36 UTC (permalink / raw) To: alsa-devel Dnia Mon, 19 Feb 2007 14:11:25 +0100 Prakash Punnoor <prakash@punnoor.de> napisał(a): > > 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. > > ACK Sorry to admit but that's true. I used to listen some of my music CD's ripped to loseless FLAC format. I am using xmms with some additional sound effects processor and it works nicely under OSS or OSS from www.opensound.com. With ALSA (xmms has native support for ALSA too) it sounds terribly and additional effects are distorted and not usable. It's of course 44100 material while card is working at 48000 so upsampling is the case. So better resampling default plugin is a must IMHO. Sound quality is very important and if we can use additional sound processing plugins which do stereo to 5.1 or headphone mode sound transformation there must be proper quality resampler because in other case results will be not acceptable for many users. Regards -- Adam Tlałka mailto:atlka@pg.gda.pl ^v^ ^v^ ^v^ ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-devel ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2007-03-21 17:24 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-19 4:01 Quality resampling code for libasound Jean-Marc Valin 2007-02-19 12:23 ` Takashi Iwai 2007-02-19 12:54 ` Jean-Marc Valin 2007-02-19 13:10 ` Takashi Iwai 2007-02-19 13:38 ` Jean-Marc Valin 2007-02-19 13:47 ` Takashi Iwai 2007-02-20 5:53 ` Jean-Marc Valin 2007-02-20 6:48 ` Jean-Marc Valin 2007-02-20 10:45 ` Takashi Iwai 2007-02-20 11:54 ` Jean-Marc Valin 2007-02-20 12:13 ` Takashi Iwai 2007-02-20 12:38 ` Jean-Marc Valin 2007-02-20 21:50 ` Fernando Lopez-Lezcano 2007-02-20 22:07 ` James Courtier-Dutton 2007-02-20 22:45 ` Jean-Marc Valin 2007-02-21 2:10 ` Jean-Marc Valin 2007-02-21 9:18 ` Jean-Marc Valin 2007-02-22 11:38 ` Takashi Iwai 2007-02-22 11:48 ` Jean-Marc Valin 2007-02-22 12:07 ` Takashi Iwai 2007-02-28 2:10 ` Jean-Marc Valin 2007-03-07 22:25 ` Takashi Iwai 2007-03-08 0:59 ` Jean-Marc Valin 2007-03-09 16:08 ` Takashi Iwai 2007-03-20 13:22 ` Jean-Marc Valin 2007-03-20 13:52 ` Takashi Iwai 2007-03-20 14:07 ` Jean-Marc Valin 2007-03-20 14:19 ` Takashi Iwai [not found] ` <4600539A.2070804@usherbrooke.ca> 2007-03-21 11:23 ` [Alsa-devel] " Takashi Iwai 2007-03-21 13:08 ` Jean-Marc Valin 2007-03-21 13:14 ` Takashi Iwai 2007-03-21 13:39 ` Jean-Marc Valin 2007-03-21 13:59 ` Takashi Iwai 2007-03-21 14:19 ` Jean-Marc Valin 2007-03-21 14:53 ` Takashi Iwai 2007-03-21 15:17 ` Jean-Marc Valin 2007-03-21 15:43 ` Takashi Iwai 2007-03-21 15:27 ` Rene Herman 2007-03-21 15:34 ` Jean-Marc Valin 2007-03-21 16:38 ` Rene Herman 2007-03-21 16:57 ` Takashi Iwai 2007-03-21 17:24 ` Takashi Iwai 2007-02-21 14:48 ` Jean-Marc Valin 2007-02-19 13:11 ` Prakash Punnoor 2007-02-19 13:36 ` Adam Tlałka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.