Re: [ecasound] ecasound-2.4.6.1 possibly disrespects LADSPA spec WRT last buffer

--- On Tue, 8/5/08, Sergei Steshenko <sergstesh@email-addr-hidden> wrote:

> From: Sergei Steshenko <sergstesh@email-addr-hidden>
> Subject: [ecasound] ecasound-2.4.6.1 possibly disrepsects LADSPA spec WRT last buffer
> To: ecasound-list@email-addr-hidden
> Date: Tuesday, August 5, 2008, 2:04 PM
> Hello All,
>
> while debugging my plugin which I can't publish
> I've noticed this:
>
> "
> MyPlugin_1020 :INFO: input_buffer_number=1020
> MyPlugin_1020 :INFO: input_buffer_number=1021
> ___input_buffer_number=1021
> MyPlugin_1020 :ERROR: STEP_SIZE=12288 is not a multiple of
> sample_count=147 at line #292 of 'MyPlugin_1020.c'
> file
> [* Controller/Processing stopped (cond) *]
> Warning: DBC_ENSURE failed - "is_running() ==
> false", eca-control-base.cpp, 298.
> [* Controller/Processing stopped (cond) *]
> Warning: DBC_ENSURE failed - "is_running() ==
> false", eca-control-base.cpp, 298.
> (eca-control-base) WARNING: Problems while shutting down
> the engine!
> Warning: DBC_ENSURE failed - "is_engine_started() !=
> true", eca-control-base.cpp, 380.
> (eca-control-objects) Disconnecting chainsetup:
> "command-line-setup".
> Warning: DBC_REQUIRE failed - "is_locked() !=
> true", eca-chainsetup.cpp, 1914.
> [* Chainsetup disconnected *]
> "
>
> - 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.
>
> ecasound was invoked with -b 2048, and until this last
> buffer sample_count
> was 2048 as expected.
>
> My plugin has other problems at the moment, but
> sample_count is set by
> host (i.e. ecasound in this case), so most likely it's
> an ecasound problem.
>
> For me sample_count absolutely needs to be constant and
> power of two
> because of ":ERROR: STEP_SIZE=12288 is not a multiple
> of sample_count=147"
> - STEP_SIZE needs to be a multiple of sample_count,
> STEP_SIZE itself
> is 3 * 4096 == 3 * (2 ** 12), etc.
>
> If it's really an ecasound problem, I guess last buffer
> should be
> zero-padded at the end.
>
> Thanks,
> Sergei.
>
>
>
>
>
> -------------------------------------------------------------------------
> 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-list

An addition - I was playing a FLAC file, and I see ecasound runs 'flac' as
a separate process, so, I guess, the last buffer grabbed from STDOUT
produced by 'flac' can be of whatever size smaller than or equal to
"normal" buffer size.

Thanks,
  Sergei.

-------------------------------------------------------------------------
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-list
Received on Wed Aug 6 16:15:05 2008