Re: [Alsa-user] mbeq_119700 issues
Brought to you by:
perex
From: Sergei S. <ste...@li...> - 2007-01-03 09:10:28
|
On Wed, 03 Jan 2007 09:22:50 +0100 Sebastian Sch=C3=A4fer <sch...@ro...> wrote: > [removed stuff] >=20 > > What does the "Speicherzugriffsfehler" word mean ? > >=20 >=20 > "Speicherzugriffsfehler" means segmentation fault - sorry for not > substituting it. Oh, sorry to hear that the segmentation fault is there. But this one appears to be of a different kind - the previous one in the port connection routine, and this one is in the run routine. Let's continue our debugging with the 'applyplugin' utility. What kind of FFTW library do you use ? Is it FFTW2 or FFTW3 ? Most importantly, is it SSE or another vector arithmetic enabled one ? The question is important because SSE-enabled FFTW requires proper alignment of buffers. I need answers to these questions in order to be able to correctly reproduce your setup. I tested the plugin before releasing using 'ams', there were no crashes and, I think, 14 cascaded instances just worked just fine on Athlon XP1900+ machine. >=20 > > Regarding the > >=20 > > " > > instantiateMChMBEq :INFO: actual 00 band bin number: 2 frequency: > > 23,4375Hz > > mbeq_119700: !!! ERROR !!! 28.2842712474619Hz band is too close to > > previous one (gets into the same FFT bin) > > mbeq_119700: either change the frequency or increase number of point is > > FFT > > " > >=20 > > message - it says what it says - you can't have such close frequencies > > under given conditions. > >=20 >=20 > I thought so, because in the documentation only sample frequencies of > 44,1 kHz were mentioned, thus I resampled to that frequency. > I will now try to rewrite as recommended by you. > But: What will happen when I try to play a file with 96 kHz? I suppose > then again frequencies would be too close, wouldn't they? >=20 > I think some automatism throwing out the closest frequencies would just > be great - at least for version 2 of the plugin :-) There is no way to do this completely automatically, and this is what README.multichannel_multiband_equalizer.txt file says on the issue: " One of the main issues is DFT/FFT spectral resolution. For N point DFT with sampling frequency Fs spectral resolution is (Fs / N). The plugin the way it is released has N =3D 4096, so for audio CD sampling frequency of 44100Hz spectral resolution is (44100 / 4096)Hz =3D 10.766602H= z. The existence of spectral resolution prevents end user from having arbitrary central band frequencies in DFT-based equalizers, central frequen= cies can only be a multiple of spectral resolution. ". That is, if you want the thing to work at 96kHz sampling rate, either increase N or decrease the equalizer spectral resolution, i.e. have less bands per octave. The problem is that the code is generated before the plugin is called, i.e. the code is first generated, then compiled, only then the plugin is called, and sampling frequency becomes known only after the plugin is calle= d. In more detail - ALL the control ports MUST be known before compilation, and once they've been created, they can't be removed. There is a mathematical problem with two frequencies falling onto the same FFT bin (I mean, your "throwing out the closest frequencies" words) and the problem is division by zero. Regards, Sergei. --=20 Visit my http://appsfromscratch.berlios.de/ open source project. |