Sample Rate Conversion Quality in ALSA

Sample Rate Conversion Quality in ALSA

[Marc Brooker]

Hello,

I am new to the ALSA development, and would be interested in
contributing in future.

After installing the latest Ubuntu on my home machine, I noticed that
dmix is enabled by default. This is a very good move in my opinion, as
it makes Linux sound much more transparent to the end user. However, I
was concerned with the quality of the mixing algorithm and sample rate
conversion used by dmix.

The conclusions I came to after reading the source were the following
(please correct me if I am wrong).

1) The algorithm used by dmix looks to be fairly good. While my x86
assembler is rusty (I read the version in pcm_dmix_i386.h) it seems to
keep 24 bits of significant audio data and is unlikely to cause any
major sound quality problems.

2) The sample rate conversion algorithm (linear) is very poor. I did
some loopback measurements with both real sample material and
synthetic waveforms and it seems to add several percent harmonic
distortion in some cases.

The rate module (pcm_rate.c) from alsa-plugins adresses problem
effectively by using high quality SRC from libsamplerate. The only
problem here is that it is fairly tricky to enable (it requires adding
defaults.pcm.rate_converter "samplerate" to .asoundrc) and it isn't
distributed by default in Ubuntu or Debian unstable (I don't know
about other distributions). While this is a distribution issue and not
an ALSA bug, users are likely to blame it on ALSA.

Is any consideration being given to the quality of SRC in ALSA? I
understand that the tradeoff between quality and performance is an
important one. In my mind, however, it would make sense to make it
easier for the end user to enable higher quality SRC on fast machines.
The low quality (but fast) SRC algorithm currently used will degrade
sound quality for some users and is likely to reflect badly on the
sound experience in Linux.

I would be happy to take part in the improvement of the current
situation but would be interesting in hearing developers opinions
before writing a patch.

Cheers

Marc Brooker

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[James Courtier-Dutton]

Marc Brooker wrote:
> Hello,
>
> I am new to the ALSA development, and would be interested in
> contributing in future.
>
> After installing the latest Ubuntu on my home machine, I noticed that
> dmix is enabled by default. This is a very good move in my opinion, as
> it makes Linux sound much more transparent to the end user. However, I
> was concerned with the quality of the mixing algorithm and sample rate
> conversion used by dmix.
>
>
> Cheers
>
> Marc Brooker
>   
The problem is actually far more complicated than you described. A fair 
amount of ALSA core will have to be modified to really fix the problem.
The main problem is the buffer and period sized as they pass through dmix.
For example, if the sound card hardware is running with 1024 samples per 
period at 48000, and an application wished to use a sample rate of 
44100, the application should really get 940.8 samples per period. That 
is nor possible, so the application gets 940. dmix then tries to convert 
940 samples to 1024 samples ready for the hardware. So, even if the dmix 
algorithm used the super high quality sample rate conversion function, 
the actual rate change applied would still be slightly off.

James


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Takashi Iwai]

At Mon, 21 Aug 2006 13:45:46 +0100,
James Courtier-Dutton wrote:
> 
> Marc Brooker wrote:
> > Hello,
> >
> > I am new to the ALSA development, and would be interested in
> > contributing in future.
> >
> > After installing the latest Ubuntu on my home machine, I noticed that
> > dmix is enabled by default. This is a very good move in my opinion, as
> > it makes Linux sound much more transparent to the end user. However, I
> > was concerned with the quality of the mixing algorithm and sample rate
> > conversion used by dmix.
> >
> >
> > Cheers
> >
> > Marc Brooker
> >   
> The problem is actually far more complicated than you described. A fair 
> amount of ALSA core will have to be modified to really fix the problem.
> The main problem is the buffer and period sized as they pass through dmix.
> For example, if the sound card hardware is running with 1024 samples per 
> period at 48000, and an application wished to use a sample rate of 
> 44100, the application should really get 940.8 samples per period. That 
> is nor possible, so the application gets 940. dmix then tries to convert 
> 940 samples to 1024 samples ready for the hardware. So, even if the dmix 
> algorithm used the super high quality sample rate conversion function, 
> the actual rate change applied would still be slightly off.

Well, the problem raised in the original post is rather the usability
issue.  As mentioned there, the quality issue can be solved by using
rate plugin in alsa-plugins package.  The question is how easily one
can set it up.

IMO, it's just a problem of lack of (so-called user-friendly)
configuration tool.


Takashi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Marc Brooker]

On 8/21/06, Takashi Iwai <tiwai@suse.de> wrote:
> At Mon, 21 Aug 2006 13:45:46 +0100,
> James Courtier-Dutton wrote:
> >
> > Marc Brooker wrote:
> > > Hello,
> > >
> > > I am new to the ALSA development, and would be interested in
> > > contributing in future.
> > >
> > > After installing the latest Ubuntu on my home machine, I noticed that
> > > dmix is enabled by default. This is a very good move in my opinion, as
> > > it makes Linux sound much more transparent to the end user. However, I
> > > was concerned with the quality of the mixing algorithm and sample rate
> > > conversion used by dmix.
> > >
> > >
> > > Cheers
> > >
> > > Marc Brooker
> > >
> > The problem is actually far more complicated than you described. A fair
> > amount of ALSA core will have to be modified to really fix the problem.
> > The main problem is the buffer and period sized as they pass through dmix.
> > For example, if the sound card hardware is running with 1024 samples per
> > period at 48000, and an application wished to use a sample rate of
> > 44100, the application should really get 940.8 samples per period. That
> > is nor possible, so the application gets 940. dmix then tries to convert
> > 940 samples to 1024 samples ready for the hardware. So, even if the dmix
> > algorithm used the super high quality sample rate conversion function,
> > the actual rate change applied would still be slightly off.
>
> Well, the problem raised in the original post is rather the usability
> issue.  As mentioned there, the quality issue can be solved by using
> rate plugin in alsa-plugins package.  The question is how easily one
> can set it up.
>
> IMO, it's just a problem of lack of (so-called user-friendly)
> configuration tool.
>
>
> Takashi
>

Takashi,

You are right that the original problem is a usability one. The reason
I posted it here (instead of on the -users list) is that, in my
opinion, the current behaviour of alsa is not optimal for desktop
machines. While the extreme quality-speed tradeoff that alsa takes
would make sense on low-power desktops and embedded systems, in my
opinion a higher quality default would be better on desktops. That's
only my opinion, though, and it's clear the original developer had a
different (and possibly more valid) one.

In terms of a terse bug report, I would write "Dmix sound quality is
poor" rather than "Configuration of sample rate plugin is difficult".

There are, it seems to me, two ways to fix this for desktop users. The
first is to change the defaults to use the rate plugin. This would
also involve convincing distros to include this plugin in their
packages (which Debian and Ubuntu don't do by default, at the moment).
Another solution would be to change the alsa-lib code to a better
algorithm. This would probably involve either linking against
libsamplerate, so it isn't optimal either.

On a side note: A while ago I started writing a graphical setup
utility for .asoundrc (see www.sourceforge.net/projects/kasound) which
supported many of alsa's features and made them easier to set up. It's
less useful for the majority of people now that alsa uses dmix by
default.

Regards, and thanks for your responses

Marc Brooker

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Takashi Iwai]

At Mon, 21 Aug 2006 17:05:04 +0200,
Marc Brooker wrote:
> 
> On 8/21/06, Takashi Iwai <tiwai@suse.de> wrote:
> > At Mon, 21 Aug 2006 13:45:46 +0100,
> > James Courtier-Dutton wrote:
> > >
> > > Marc Brooker wrote:
> > > > Hello,
> > > >
> > > > I am new to the ALSA development, and would be interested in
> > > > contributing in future.
> > > >
> > > > After installing the latest Ubuntu on my home machine, I noticed that
> > > > dmix is enabled by default. This is a very good move in my opinion, as
> > > > it makes Linux sound much more transparent to the end user. However, I
> > > > was concerned with the quality of the mixing algorithm and sample rate
> > > > conversion used by dmix.
> > > >
> > > >
> > > > Cheers
> > > >
> > > > Marc Brooker
> > > >
> > > The problem is actually far more complicated than you described. A fair
> > > amount of ALSA core will have to be modified to really fix the problem.
> > > The main problem is the buffer and period sized as they pass through dmix.
> > > For example, if the sound card hardware is running with 1024 samples per
> > > period at 48000, and an application wished to use a sample rate of
> > > 44100, the application should really get 940.8 samples per period. That
> > > is nor possible, so the application gets 940. dmix then tries to convert
> > > 940 samples to 1024 samples ready for the hardware. So, even if the dmix
> > > algorithm used the super high quality sample rate conversion function,
> > > the actual rate change applied would still be slightly off.
> >
> > Well, the problem raised in the original post is rather the usability
> > issue.  As mentioned there, the quality issue can be solved by using
> > rate plugin in alsa-plugins package.  The question is how easily one
> > can set it up.
> >
> > IMO, it's just a problem of lack of (so-called user-friendly)
> > configuration tool.
> >
> >
> > Takashi
> >
> 
> Takashi,
> 
> You are right that the original problem is a usability one. The reason
> I posted it here (instead of on the -users list) is that, in my
> opinion, the current behaviour of alsa is not optimal for desktop
> machines. While the extreme quality-speed tradeoff that alsa takes
> would make sense on low-power desktops and embedded systems, in my
> opinion a higher quality default would be better on desktops. That's
> only my opinion, though, and it's clear the original developer had a
> different (and possibly more valid) one.

Yes, it's really a matter of taste.  I myself prefer a bit worse SRC
in comparison to the CPU-hogging one.

> In terms of a terse bug report, I would write "Dmix sound quality is
> poor" rather than "Configuration of sample rate plugin is difficult".
> 
> There are, it seems to me, two ways to fix this for desktop users. The
> first is to change the defaults to use the rate plugin. This would
> also involve convincing distros to include this plugin in their
> packages (which Debian and Ubuntu don't do by default, at the moment).
> Another solution would be to change the alsa-lib code to a better
> algorithm. This would probably involve either linking against
> libsamplerate, so it isn't optimal either.

Hm, I wouldn't buy the idea to create a new sample rate algorighm just
for alsa-lib.  You might be able to add some code optimizations, but
it's far smaller benift than having a same code base from the
viewpoint of maintenance and bugfix.

> On a side note: A while ago I started writing a graphical setup
> utility for .asoundrc (see www.sourceforge.net/projects/kasound) which
> supported many of alsa's features and made them easier to set up. It's
> less useful for the majority of people now that alsa uses dmix by
> default.

A graphical setup tool is neat.  There are more rooms for such a setup
tool, for example, the PCM setup suitable for the speaker presets.


One possible improvement is to decide the sample rate of the master
PCM (i.e. the hardware) later at the time the first
snd_pcm_hw_params() is used so that the optimal h/w condition can be
chosen.  But, this would result in races when two streams are opened
and set up at the very same time.


Takashi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Lee Revell]

On Mon, 2006-08-21 at 17:16 +0200, Takashi Iwai wrote:
> A graphical setup tool is neat.  There are more rooms for such a setup
> tool, for example, the PCM setup suitable for the speaker presets. 

First things first - ALSA needs a decent device enumeration API before
good setup tools can be created.

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Takashi Iwai]

At Mon, 21 Aug 2006 11:59:49 -0400,
Lee Revell wrote:
> 
> On Mon, 2006-08-21 at 17:16 +0200, Takashi Iwai wrote:
> > A graphical setup tool is neat.  There are more rooms for such a setup
> > tool, for example, the PCM setup suitable for the speaker presets. 
> 
> First things first - ALSA needs a decent device enumeration API before
> good setup tools can be created.

Sure.


Takashi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Marc Brooker]

On 8/21/06, James Courtier-Dutton <James@superbug.co.uk> wrote:
> Marc Brooker wrote:
> > Hello,
> >
> > I am new to the ALSA development, and would be interested in
> > contributing in future.
> >
> > After installing the latest Ubuntu on my home machine, I noticed that
> > dmix is enabled by default. This is a very good move in my opinion, as
> > it makes Linux sound much more transparent to the end user. However, I
> > was concerned with the quality of the mixing algorithm and sample rate
> > conversion used by dmix.
> >
> >
> > Cheers
> >
> > Marc Brooker
> >
> The problem is actually far more complicated than you described. A fair
> amount of ALSA core will have to be modified to really fix the problem.
> The main problem is the buffer and period sized as they pass through dmix.
> For example, if the sound card hardware is running with 1024 samples per
> period at 48000, and an application wished to use a sample rate of
> 44100, the application should really get 940.8 samples per period. That
> is nor possible, so the application gets 940. dmix then tries to convert
> 940 samples to 1024 samples ready for the hardware. So, even if the dmix
> algorithm used the super high quality sample rate conversion function,
> the actual rate change applied would still be slightly off.
>
> James
>
>

James

Let me see if I understand you correctly. In the scenario that you
presented the application is told that there are 940 samples per
period. ALSA, internally, converts these to 1024 samples per period at
48kHz sample rate. So the material (sampled at 44100Hz) is played back
at a rate of 44062Hz? I don't know enough about the field to know if
this error (0.08%) will be audible.

There doesn't seem (at first glance, my knowledge of the ALSA source
is limited) to be an easy solution to this problem. It might be naive,
but wouldn't it be better to report 941 as the buffer size to the
application - this way the error is smaller (but still not gone).

It seems to me that using a higher quality SRC function would lead to
some improvement in playback quality.

Cheers

Marc

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[John Rigg]

On Mon, Aug 21, 2006 at 03:02:07PM +0200, Marc Brooker wrote:
> Let me see if I understand you correctly. In the scenario that you
> presented the application is told that there are 940 samples per
> period. ALSA, internally, converts these to 1024 samples per period at
> 48kHz sample rate. So the material (sampled at 44100Hz) is played back
> at a rate of 44062Hz? I don't know enough about the field to know if
> this error (0.08%) will be audible.

To put that in perspective, a semitone is around 6% change in pitch.
The error here looks small at 0.08% but it's enough to make a musical
note sound out of tune.

John

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Marc Brooker]

On 8/21/06, John Rigg <ad@sound-man.co.uk> wrote:
> On Mon, Aug 21, 2006 at 03:02:07PM +0200, Marc Brooker wrote:
> > Let me see if I understand you correctly. In the scenario that you
> > presented the application is told that there are 940 samples per
> > period. ALSA, internally, converts these to 1024 samples per period at
> > 48kHz sample rate. So the material (sampled at 44100Hz) is played back
> > at a rate of 44062Hz? I don't know enough about the field to know if
> > this error (0.08%) will be audible.
>
> To put that in perspective, a semitone is around 6% change in pitch.
> The error here looks small at 0.08% but it's enough to make a musical
> note sound out of tune.
>
> John
>

Would it not be possible to abuse the SRC algorithm to fix this pitch
shift when it does the rate convertion. Instead of setting the source
rate to 44100Hz (the real rate of the material), you set it to the
rate that ALSA's rounding off causes (44062Hz, unless I am mistaken).
In this way, as far as I can see, the SRC algorithm would fix the
pitch shift. Or is this a stupid idea?

On a related note, on an Athlon64 3200+ running Ubuntu Dapper for i386
with backported alsa-libs 1.0.11 and alsa-plugins 1.0.11 (with
samplerate plugin) cpu usage figures (while playing a VBR mp3 using
gstreamer):
standard ALSA linear: 2%
samplerate: 6%
samplerate_medium: 9%
samplerate_best: 20%

>From this it seems that samplerate_best is too costly, but samplerate
and samplerate_medium would be usable on most modern hardware.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Lee Revell]

On Mon, 2006-08-21 at 21:07 +0200, Marc Brooker wrote:
> On a related note, on an Athlon64 3200+ running Ubuntu Dapper for i386
> with backported alsa-libs 1.0.11 and alsa-plugins 1.0.11 (with
> samplerate plugin) cpu usage figures (while playing a VBR mp3 using
> gstreamer):
> standard ALSA linear: 2%
> samplerate: 6%
> samplerate_medium: 9%
> samplerate_best: 20%
> 
> >From this it seems that samplerate_best is too costly, but samplerate
> and samplerate_medium would be usable on most modern hardware.
> 

It would be useful to have the same numbers for the low end of "modern
hardware", like a 1Ghz fanless Via C3 board, or a Geode - the type of
thing people use for MythTV boxes and what not.

Lee


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[Marc Brooker]

On 8/21/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Mon, 2006-08-21 at 21:07 +0200, Marc Brooker wrote:
> > On a related note, on an Athlon64 3200+ running Ubuntu Dapper for i386
> > with backported alsa-libs 1.0.11 and alsa-plugins 1.0.11 (with
> > samplerate plugin) cpu usage figures (while playing a VBR mp3 using
> > gstreamer):
> > standard ALSA linear: 2%
> > samplerate: 6%
> > samplerate_medium: 9%
> > samplerate_best: 20%
> >
> > >From this it seems that samplerate_best is too costly, but samplerate
> > and samplerate_medium would be usable on most modern hardware.
> >
>
> It would be useful to have the same numbers for the low end of "modern
> hardware", like a 1Ghz fanless Via C3 board, or a Geode - the type of
> thing people use for MythTV boxes and what not.
>
> Lee
>
>

That's fair enough. I know that many people use Linux and ALSA on
lower end hardware which is doing other stuff (like MythTV) where
cycles are short. It's a really difficult problem - one default offers
poor sound quality and one chews CPU cycles.

I have spent some time this evening measuring the performance of the
standard resampler in ALSA versus the libsamplerate plugin.

First, I tested in the built in resampling code. On a 500Hz sine wave,
THD is fairly good (at -71dB) but SINAD (signal to noise and
distortion) is terrible at about 32dB. The picture is worse with 5kHz
sine wave - SNR is 30dB. Finally, on a 16kHz sine wave, SNR is 9dB
with an alias at 20kHz at -20dB and another at 8kHz at -30dB.

With samplerate_best and a 16kHz square wave, SNR is 70dB and the
strongest image is at 8kHz at -90dB. samplerate (fast) and
samplerate_medium performed nearly as well, with a slightly lower
cutoff frequency. The low SNR is probably caused by the recording
hardware. samplerate_order and samplerate_linear do no better than the
built in code.

Tests were performed by playing 44100 material through dmix, through
the Wolfson DAC on my AV710 card, and captured at 48000Hz using
AV710's rather poor line in. Analysis was done with baudline
(www.baudline.com).

I hope developers are not taking my arriving on this list and shouting
my mouth off the wrong way. I really appreciate the work you guys do
(and have done) and would like to contribute.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: Sample Rate Conversion Quality in ALSA

[John Rigg]

On Mon, Aug 21, 2006 at 09:07:31PM +0200, Marc Brooker wrote:
> On a related note, on an Athlon64 3200+ running Ubuntu Dapper for i386
> with backported alsa-libs 1.0.11 and alsa-plugins 1.0.11 (with
> samplerate plugin) cpu usage figures (while playing a VBR mp3 using
> gstreamer):
> standard ALSA linear: 2%
> samplerate: 6%
> samplerate_medium: 9%
> samplerate_best: 20%
> 
> From this it seems that samplerate_best is too costly, but samplerate
> and samplerate_medium would be usable on most modern hardware.

If you're running an i386 distro you're only using half of the
Athlon64's registers. It would be interesting to see if that
samplerate_best CPU load is reduced in 64-bit mode.

John

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642