Re: Best way to implement a driver-level equalizer?

[Takashi Iwai <tiwai@suse.de>]

Hi,

At Sun, 1 Jun 2003 13:19:25 -0500,
Rich Tollerton wrote:
> 
> Hi, I'd like to try my hand at implementing a good equalizer at either
> the alsalib or alsadriver level, so that all my programs (not just xmms)
> are properly equalized.  By 'good' I mean: 16+ bands, ~10hz transition
> widths, 32-bit internal precision or better, like shibatch's equalizer
> (http://shibatch.sourceforge.net/) which is used to good effect in
> foobar2000 on windows.
> 
> There are several ways to go about this, and I'm not really sure of the
> best one. I hope some of you have some thoughts you could contribute on
> the matter.
> 
> 1) Implement the equ as an as10k1 dsp program and reload it whenever
> I want to tweak the equalizer. This is probably the only way to
> implement the equalizer so that it utilizes my sblive's hardware mixing
> capabilities. However it obviously won't work once I get a better
> sound card, the filter size I can implement is quite limited
> (1k data size so 200 taps at most is feasible - that's far, far
> too little for transition widths on the order of 10hz), there's 
> not enough internal precision to reasonably attempt an IIR filter,
> and no released method for actually LOADING an as10k1-compiled .bin
> file currently exists.
 
yeah, that's one of the big TODOs.

> 2) Implement the equ as a LADSPA plugin, and use a 'ladspa' plugin type
> in .asoundrc to load it.  This is by far the most flexible of these
> solutions. As I understand the alsalib architecture though, the plugin
> would be applied to the data in userspace, so I'm concerned about
> latency issues.  Additionally I've spend a few hours getting the
> .asoundrc ladspa plugin to work at all, with no success; it appears to
> be unmaintained since 2001. I'm not sure how to get this working with
> OSS programs.

yep, also not tested well.
also, there is no good (dynamic) control method for the plugin.
in general, it's possible to write another plug-in effect engine
for alsa-lib, if the float-int conversion costs too much.

> 3) Implement the equ in kernel mode right before the sound data is
> passed to the card. This is, of course, an ungodly hack, as I don't
> see an existing interface to do this sort of thing. The equalizer
> would need to either be linked in statically to snd-pcm, or an
> infrastructure would be created to allow other modules to insert
> themselves into the processing chain (thus making it less of a hack). 
> I'm leaning towards the former. :)
 
i won't buy this -- at least, it won't go into the official tree :)


this is really a good question, and atm, there is no proper answer for
this yet.

in general, portability and effectivity is complementary.
that's true also in this case.

once if we have a working emu10k1 dsp loader, it would be the cheapest
and fastest.  on audigy, there are more GRPs, so the functions above
might be able to be implemented.

OTOH, user-space implementation is, of course, much more portable and
beniftable for other people, too.  for this, it would be nice to
have "dynamic" user-defined controls, too, which can be accessed via
normal control API, so that a mixer program can show/control it.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.