On Mi, 2007-01-03 at 11:11 +0200, Sergei Steshenko wrote: > On Wed, 03 Jan 2007 09:22:50 +0100 > Sebastian Schäfer <[EMAIL PROTECTED]> wrote: > > > > [removed stuff] > > > > > > What does the "Speicherzugriffsfehler" word mean ? > > > > > > > "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 ? >
It's FFTW3, but I do not know whether SSE is used as I just installed the Debian package (from unstable). Its version is: fftw3-3.1.2-1 > 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. > > > > > > Regarding the > > > > > > " > > > 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 > > > " > > > > > > message - it says what it says - you can't have such close frequencies > > > under given conditions. > > > > > > > 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? > > > > 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 = 4096, so for audio CD sampling > frequency of 44100Hz spectral resolution is (44100 / 4096)Hz = 10.766602Hz. > > The existence of spectral resolution prevents end user from having > arbitrary central band frequencies in DFT-based equalizers, central > frequencies > 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 called. > > 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. > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Alsa-user mailing list Alsa-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-user
