Best way to implement a driver-level equalizer?

Best way to implement a driver-level equalizer?

[Rich Tollerton]

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.

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.

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. :)


Ideally I could write this so that only the post-mixed sound is
equalized, but if the hardware mixer output isn't exposed to us then
that's not really possible (unless I use dmix, which I don't want to
do). If I keep the CPU usage down then I don't think this is an issue.

Any comments gladly welcome.

-- 
Rich Tollerton <rtollert@tranquility.net>


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5

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

[Takashi Iwai]

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.