Hi,
On Tue, 5 Aug 2008, Sergei Steshenko wrote:
> - please pay attention to "sample_count=147".
>
> IIRC, LDSPA spec demands two things:
>
> 1) sample_count should be a power of 2;
> 2) sample_count should not change after plugin instance is created -
> this is important for block transforms like FFT.
now while I agree this would be a convenient feature, I think current
LADSPA spec does not mandate either (1) or (2). Thus even if ecasound
would follow these requirements, some other LADSPA hosts might not. You
might be mixing LADSPA with JACK, as JACK indeed requires both (1) and (2)
in its public client API. The new LV2 spec handles this a bit differently
as it has a separate "fixed-buffersize" extension plugins may use, see:
http://tapas.affenbande.org/wordpress/?page_id=53
> ecasound was invoked with -b 2048, and until this last buffer sample_count
> was 2048 as expected.
Yes, you are correct. At the end of a stream, ecasound will pass
a partial buffer to the LADSPA plugins.
If you need to only work with ecasound, you can assume that the buffer
area always has space for 2048 (or whatever is set with '-b') samples,
even if ecasound passes a smaller SampleCount to run/run_adding().
For a more general work-around, take a look at for instance Steve Harris'
"MultiEQPlugin" plugin (id 1197):
Hope this helps!
-- ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ecasound-list mailing list Ecasound-list@email-addr-hidden https://lists.sourceforge.net/lists/listinfo/ecasound-listReceived on Sat Aug 9 12:15:09 2008
This archive was generated by hypermail 2.1.8 : Sat Aug 09 2008 - 12:15:10 EEST