On Mon, 08 Jan 2007 10:43:38 +0100Sebastian Schäfer <schaefer@xxxxxxx> wrote: > On Fr, 2007-01-05 at 18:53 +0200, Sergei Steshenko wrote:> > On Fri, 05 Jan 2007 10:49:11 +0100> > Sebastian Schäfer <schaefer@xxxxxxx> wrote:> > > > [deleted]> > > Ah, of course playback is fine when I do not use the mbeq plugin.> > > Behaviour stays the same when I use another LADSPA plugin.> > > > > > [deleted]> > > > If you can, try to play with ALSA buffers at system level - for> > the case of 8192 length FFT I'd suggest 4096 samples long ALSA buffers,> > so FFT will be performed upon arrival of every ALSA buffer, and CPU> > load will be even.> > > > And I do not know how to change ALSA buffers length at system> > level - to tweak asound.conf ?> > > > Or to create .asoundrc in your home dir and set buffer lengths in it ?> > > > > Adjusting the buffer size really did the trick!> It's done by echoing something in /proc/asound/card0/pcm0p/sub0/prealloc> The maximum value is given in prealloc_max.> Now I just have to try and adjust the plugin for use with 48 kHz.> > (Wish for the next release: A config line where the sample rate to be> used can be given and bands too close will automatically get thrown out> or whatever. At least if that is possible, of course.)> > > P.S. Since a bug was found and fixed, I'm thinking about a followup> > release, and the example of mbeq_119700 has just proved yet another> > time that developers can not be trusted testers when it comes to testing> > their own stuff, so, will you help me testing the next release ?> > > > I think that the Perl part you've apparently used to configure the> > plugin will remain the same - the pieces intended for configuration,> > I mean. So it will hopefully won't take long to configure and test.> > > I would be very happy to help you!> > Best regards,> Sebastian> > > Sebastian, where do I find the value of prealloc_max ?Only in ALSA source ? Or in kernel source ? Thanks for the info, now I myself know how do it ! :-) Regarding "A config line where the sample rate to beused can be given and bands too close will automatically get thrown outor whatever. At least if that is possible, of course.)" - this is very difficult at best - the problem is, as I wrote, thatwhen the Perl code used to actually the generate the "C" code isrun, sample rate is not yet known. And in the definition of LADSPA each time sample rate changes theplugin should be reinstantiated, that's because there canbe things (DSP coefficients, delay line lengths, etc.) which arefunctions of sample rate. Again, joining frequencies at runtime doesn't seem to be an option,because this means joining control ports, i.e changing their number,which is not possible, or blocking them, which adds to code complexity. As a compromise I can add to the Perl code something likeexpected_sample_rate entity, expected_fft_length, so the code will try to adjust bands/ports according to the two entities. However, still, if, say, the bands are as close as possible at48kHz, and suddenly the plugin is used at 96kHz, it will fail. Regards, 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
