Subject: Re: [ecasound] Questions arising while using ECI
From: Kai Vehmanen (k@eca.cx)
Date: Mon Dec 18 2000 - 03:36:56 EET
On Thu, 14 Dec 2000, S. Massy wrote:
> - I've found out that to know the length of an object (a file) it has
> to have been placed in a chainsetup that has been connected at one
Yes, files and devices are not accessed until you connect
the chainsetup. If this wasn't the case, it would be for
instance impossible to have to chainsetups with '/dev/dsp' (you can't
open it twice for read/write). At one point ecasound quickly opened files,
checked the file length, and then closed them. This ended up causing
problems in certain circumstances (for instance, if using pipes,
the additional open&close broke the connection before any data was
processed).
> time. Thus in a setup where you want to set a processing time (-t)
> based on the length of a file, you have to:
[...]
> This is no great bother, but I'd like to know if there's a quicker or
> more efficient way to do it.
Unfortunately no. There are certain things that require constant switching
between connected and disconnected modes. Some of these things ecasound
does automatically. For instance, if you issue an ia-mode command that
requires chainsetup to be connected (like "start"), ecasound will try to
automatically connect the currently selected chainsetup. But none of
this works for command-line switches (like '-t').
You can actually use "cs-set" here. "cs-set -t:10" should work in all
circumstances. If no chainsetup is selected, it'll return an error,
if the chainsetup is connected, it will disconnect it, perform "-t:10",
and then reconnect.
> - What is preferred when setting i/o's, chainops and so on? As I see
> there is two approaches: command-line fashion vs. iam fashion. So for
> example "-o:/dev/dsp" is equal to "aio-add-output /dev/dsp", is that
> right? If so, is there a preferred way of these two or is it just a
EIAM commands should be preferred. I've explained one the reasons above.
Generally, EIAM-commands have better defined semantics.
> - Maybe it would be nice if some of the most trivial commands were
> turned into their own functions with their error reporting
> integrated. For example, every apps using ecasound has to use
> cs-connect or start. I know it goes against the thought of "as simple
> and clean as possible" which was the chief thought while developing
> this API, on the other hand it might simplify (or avoid redundant
> code) things in some cases.
Actually I have nothing against adding more functions to the ECI
implementations. So if you have implemented a small set of C-functions
based on the ECI API (and I think most people writing ECI apps will
have some sort of collection of helper functions), it can be in some
point included to libecasoundc. The only catch is that these helper
routines are not necessarily ported to other implementations.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Mon Dec 18 2000 - 03:13:45 EET