Re: mbeq_119700 issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 04 Jan 2007 10:47:56 +0100Sebastian Schäfer <schaefer@xxxxxxx> wrote:
> On Do, 2007-01-04 at 11:36 +0200, Sergei Steshenko wrote:> > On Thu, 04 Jan 2007 10:25:05 +0100> > Sebastian Schäfer <schaefer@xxxxxxx> wrote:> > > > [stuff deleted]> > > > > > OK, I now used you initial version from yesterday and applied the> > > changes you mailed me last night.> > > > [stuff deleted]> > > > Sebastian, you are applying suggested by me changed to the version> > you modified, as you write it yourself and as the printout shows - my> > version does not have _C, _LFE, _LS, _RS channels.> > > > I requested to try the UNMODIFIED version of mine - I can't see what> > modifications you've made, I have never had NULL pointers, etc.> > > > Please first try the unmodified version - I hope it's not a problem> > to find a stereo WAV file to test it.> > > > If/when the unmodified version works, we'll try to modify it step by> > step to suit your needs.> > > > OK, bit of a misunderstandment on my side.> I know compiled your completely unmodified version:> > --------------------------> # applyplugin test.wav test_equalized.wav /usr/lib/ladspa/mbeq_119700.so> MChMBEq 3 3 3 3 3 3 3 3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3 -3> -3 -3 -3 -3 -3 -3 -3 -3
[stuff deleted]
> Segmentation fault> ------------------> > > Regards,> >   Sergei.> > > > > -------------------------------------------------------------------------
OK, now that we see that the unmodified version segfaults pleaseapply just the fprintfs I suggested in order to see what is happeningto alignment and FFTW plans.
I mean, the proposed
  fprintf(stderr, "just after plan calculation: (*plugin_data).plan_rc$suffix=%08lx at line number %d\\n", (unsigned)(*plugin_data).plan_rc$suffix, __LINE__);
      fprintf(stderr, "just before using the plan: plan_rc$suffix=%08lx at line number %d\\n", (unsigned)plan_rc$suffix, __LINE__);
lines; by the way, it I think it would be cleaner to use '(unsigned long)'rather than the "(unsigned)" type casting - IIRC the compiler issueswarnings in the latter case, but does the right thing since on x86 thetypes are the same.

Also, though it shouldn't matter, please use the 0 control valuesI've used. The point is that db table lookup mechanism may be broken(hard to believe, but it is possible), so let's not introduce newfactors for a time being.
Thanks,  Sergei.
-- Visit my http://appsfromscratch.berlios.de/ open source project.
-------------------------------------------------------------------------Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT & business topics through brief surveys - and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________Alsa-user mailing listAlsa-user@xxxxxxxxxxxxxxxxxxxxxxxxxx://lists.sourceforge.net/lists/listinfo/alsa-user

[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux