alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Marc Brooker <marcbrooker@gmail.com>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: Sample Rate Conversion Quality in ALSA
Date: Mon, 21 Aug 2006 17:16:00 +0200	[thread overview]
Message-ID: <s5hfyfqqfv3.wl%tiwai@suse.de> (raw)
In-Reply-To: <b5ee41f40608210805i1a4ba369sd4a3eb0d2b49176@mail.gmail.com>

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

  reply	other threads:[~2006-08-21 15:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-21 10:16 Sample Rate Conversion Quality in ALSA Marc Brooker
2006-08-21 12:45 ` James Courtier-Dutton
2006-08-21 12:54   ` Takashi Iwai
2006-08-21 15:05     ` Marc Brooker
2006-08-21 15:16       ` Takashi Iwai [this message]
2006-08-21 15:59         ` Lee Revell
2006-08-21 16:06           ` Takashi Iwai
2006-08-21 13:02   ` Marc Brooker
2006-08-21 15:03     ` John Rigg
2006-08-21 19:07       ` Marc Brooker
2006-08-21 19:15         ` Lee Revell
2006-08-21 20:16           ` Marc Brooker
2006-08-21 20:15         ` John Rigg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hfyfqqfv3.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=marcbrooker@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).