Subject: Re: [ecasound] ecasound-2.1dev2 good and not-so-good
From: Kai Vehmanen (k_AT_eca.cx)
Date: Tue Oct 23 2001 - 02:20:49 EEST
On Mon, 22 Oct 2001, John S. Denker wrote:
>
> First of all: The synchronization in 2.1dev2 appears to be working great.
> I am seeing "usually" exact sync. The sync error is much less than one
> sample (at 44100 samples per sec) i.e. much less than 22 microseconds.
This is very good to hear! And it might be that...
> I say "usually", because sometimes things go bonkers and I get a completely
> different result. It might be off by half a sample (11 microseconds) or
> something simple like that, but the result is horrible change in the
...2.1dev3 works even better. I haven't changed the actual sync-code,
but I have changed the default buffering mode for multitrack-setups from
-B:rtlowlatency to -B:rt. This should improve reliability.
On the other hand, the error you mention still seems pretty small, so it
might not be related to the buffering mode. Have you run ecasound as root?
> ==============================================================
> Some minor gripes and suggestions:
> That's a great concept, and it often works as advertised, but the
> ecasound makefile appears to be a bit naughty.
> It makes numerous attempts to escape from the prefix-directory.
[...]
> egrep -i '[^-]error|warning' bar
> libtool: install: warning: remember to run `libtool --finish /usr/local/lib'
> libtool: install: warning: remember to run `libtool --finish /usr/local/lib/ecasound-plugins'
These shouldn't happen - did you run 'make clean ; rm config.cache' before
running './configure' again? On my system, both the libs and the
'ecasound-plugins' dir are installed cleanly under the custom prefix-dir.
> /usr/bin/install -c .libs/libpyecasound.so /usr/lib/python1.5/site-packages/libpyecasound.so /usr/bin/install: cannot remove `/usr/lib/python1.5/site-packages/libpyecasound.so':
> Permission denied
> make[2]: *** [install-libLTLIBRARIES] Error 1
This is a real problem. Python modules can only installed to one place
(afaik), so here ecasound won't honor the prefix. Configuring with
--disable-pyecasound helps here. And this should be the only place we
brake the --prefix definition. I don't know if there's a cleaner
solution to this.
> ./ecasound -f:32,12,44100,i -i:alsahw,0,0 -o:null
[...]
> ERROR: [ECA-SESSION] : "(eca-chainsetup-parser) Format of input alsahw not recognized."
Yup, ALSA is compiled as a native plugin, and you have
/usr/local/lib/ecasound-plugins in your '~/.ecasoundrc'.
> (In contrast, when I invoke the v2.0.2 version that is installed in the system
> area, things work normally.)
... yes as it finds the plugins from the abovementioned directory.
> 2) These are remarkably uniformative error messages. I tend to use ecasound with
> rather complex arguments. At the very least, it would be nice for the
> error message to say which option it thought it was parsing at the time
> of the error. Also, "expected for 3" is not English. Perhaps "...; expected 3"
> would be better.
Well this is one department I could use some help. First of all, I'm not a
native English-speaker, and second, I've used ecasound for a _long_ time,
so I've grown used to the current error messaging. I know this is bad, but
it's not as easy to fix as it sounds.
> 3) The "Format of input" error message is equally uninformative. This message is
> commonly generated when an input file does not exist. Saying it has an unrecognized
> format when it doesn't exist at all is misleading.
This is perhaps the best way to help - to mention a distinct problem
case; how did you get the error, what did you expect, and of course, what
should be reported by ecasound.
As for the above message, I changed it to "Unknown input object type
'alsahw'".
> Also, in my case, the problem is that alsahw should have been recognized as a keyword
> but is apparently not working right. It sure would be nice to get an error msg
> that tells us something about the nature of the error.
As ecasound couldn't find the ALSA-plugins, it couldn't register it to its
internal object map. As a result, nothing is known about "alsahw", or any
other ALSA types.
> Minor request #1: Better error messages:
Suggestions are welcome. :)
> Minor request #2: A better way of experimenting with ecasound, such as a working
> --prefix=PATH... option.
> Becoming root and installing experimental versions on top of the "normal" version is
> an unattractive option, because we have a multi-person team using this hardware and
> it's not good when my work interferes with other folk's work.
Yes, I agree this is important. If you find more errors with --prefix, I
do want to get them fixed. I use --prefix all the time myself, but I don't
necessarily catch all the errors (as the next thing, I'll check whether my
user account has any extra priviledges to /usr/local on my system..).
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Oct 23 2001 - 02:17:14 EEST