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. _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
