Quality resampling code for libasound

Quality resampling code for libasound

[Jean-Marc Valin]

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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[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. 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Prakash Punnoor]

[-- 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

Re: Quality resampling code for libasound

[Adam Tlałka]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

[-- 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

[-- 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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

>>> 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

Re: Quality resampling code for libasound

[Fernando Lopez-Lezcano]

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

Re: Quality resampling code for libasound

[James Courtier-Dutton]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

[-- 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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

[-- 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

[-- 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

[-- 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: [Alsa-devel] Quality resampling code for libasound

[Rene Herman]

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.

Re: [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin]

> 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

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Rene Herman]

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.

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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

Re: [Alsa-devel] Quality resampling code for libasound

[Takashi Iwai]

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;