Re: Sample Rate Conversion Quality in ALSA

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Mon, 21 Aug 2006 17:05:04 +0200,
Marc Brooker wrote:
> 
> On 8/21/06, Takashi Iwai <tiwai@xxxxxxx> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux