Possible inconsistency between libecasoundc and NetECI

[Joel Roth-2]

I found a small bug, either in Ecasound or in Audio::Ecasound.

If I issue 'int-cmd-list' via NetECI, the commands are
separated by commas, as per the specification in 'man
ecasound-iam'.  I get the same result if I issue the command
in interactive mode Ecasound.

However, I find that if I issue 'int-cmd-list' via libecasoundc
(via Audio::Ecasound), the commands in the return string
are separated by spaces.

This is using recent Ecasound (2.6.0),

Not an issue for me (well, already resolved). I report in
case there may be other, similar bugs.

Regards,

--
Joel Roth

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Kai Vehmanen]

Hi,

On Sat, 10 Oct 2009, Joel Roth wrote:

> If I issue 'int-cmd-list' via NetECI, the commands are
> separated by commas, as per the specification in 'man
> ecasound-iam'.  I get the same result if I issue the command
> in interactive mode Ecasound.

hmm, 'int-cmd-list' returns a list of strings, so commas are not
necessarily used as separators.

> However, I find that if I issue 'int-cmd-list' via libecasoundc
> (via Audio::Ecasound), the commands in the return string
> are separated by spaces.

The C ECI API allows to access each string list item separately via
'eci_last_string_list_item(int n)', and the low-level Audio::Ecasound
seems to provide these as well (eci_last_string_list* functions). But it
would seem eci() function in Audio::Ecasound returns string lists a bit
differently.

E.g. the relevant code in Ecasound.pm:
--cut--
    } elsif($type eq 'S') {
         my $count = $self->last_string_list_count();
         # differentiate from () err when ambiguous
         return ('') unless ($count && $self->on_error);
         my @ret;
         for my $n (0..$count-1) {
             push @ret, $self->last_string_list_item($n);
         }
         return @ret;
--cut--

.. so commas are not used as a separator, but instead an array of items is
returned (and assuming I'm deciphering the perl logic correctly, the
return value is a normal perl array).

But yeah, a bit confusing, but AFAIK still following the ECI docs. What do
you think..?

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list

[Joel Roth-2]

On Sun, Oct 11, 2009 at 01:35:40PM +0300, Kai Vehmanen wrote:

> Hi,
>
> On Sat, 10 Oct 2009, Joel Roth wrote:
>
> > If I issue 'int-cmd-list' via NetECI, the commands are
> > separated by commas, as per the specification in 'man
> > ecasound-iam'.  I get the same result if I issue the command
> > in interactive mode Ecasound.
>
> hmm, 'int-cmd-list' returns a list of strings, so commas are not
> necessarily used as separators.
>
> > However, I find that if I issue 'int-cmd-list' via libecasoundc
> > (via Audio::Ecasound), the commands in the return string
> > are separated by spaces.
>
> The C ECI API allows to access each string list item separately via
> 'eci_last_string_list_item(int n)', and the low-level Audio::Ecasound
> seems to provide these as well (eci_last_string_list* functions). But it
> would seem eci() function in Audio::Ecasound returns string lists a bit
> differently.
>
> E.g. the relevant code in Ecasound.pm:
> --cut--
>     } elsif($type eq 'S') {
>          my $count = $self->last_string_list_count();
>          # differentiate from () err when ambiguous
>          return ('') unless ($count && $self->on_error);
>          my @ret;
>          for my $n (0..$count-1) {
>              push @ret, $self->last_string_list_item($n);
>          }
>          return @ret;
> --cut--
>
> .. so commas are not used as a separator, but instead an array of items is
> returned (and assuming I'm deciphering the perl logic correctly, the
> return value is a normal perl array).

Ack. I should have looked myself.
 
> But yeah, a bit confusing, but AFAIK still following the ECI docs. What do
> you think..?

I'm embarrassed to say I didn't even look at my own code.  <blush>

I was returning the result as "@result", in which
case Perl kindly joins the elements with spaces.

Adding to my confusion, I find that the *-register commands
use newline as a separator, which seems sensible enough.

ladspa-register returns output as _pairs_ of lines.

That's all okay with me. I look forward to the new
features and fixes of 2.7!

Joel

--
Joel Roth

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Ecasound-list mailing list
Ecasound-list@...
https://lists.sourceforge.net/lists/listinfo/ecasound-list