Subject: Re: [ecasound] update: ECI API
From: Kai Vehmanen (k@eca.cx)
Date: Fri Dec 01 2000 - 02:08:15 EET
On Wed, 29 Nov 2000, Robert Jonsson wrote:
> I was thinking about something similar.... I think.... It really boils
> down to an event system. This might not be the right thing for a
> "simple" control interface, it is however very useful for the more
> advanced applications out there...
Exactly. This is just what I was trying to describe in my previous
mail. There's a big difference between the ECI-client initiating the
communication, and engine-initiated communication (=events). One thing to
remember is that the ia-mode parser (module inside libecasound) and
the actual engine run in separate threads. The engine thread is written
to be fast, and there's very little happening apart from the
processing itself (no memory allocation, strings or char arrays are not
used, blocking i/o is only used when reading/writing from/to soundcards).
At the moment, the only event-style ia-mode command available is
"run". Unlike "start", "run" blocks the ia-parser thread until the
processing has finished.
[ECI example]
> The program is in a loop while waiting for things to happen. This might
> be okay when the eca setup is small. But in something like heteca i
> would think it could get both inefficient and rather sluggish. In the
> example you only get status updates once in a second.
> If ecasound somehow (not sure of the best way, I'm not experienced with
> the internals of ecasound) could propagate
> status/error/property-information to the host application I think these
> types of issues could be erased efficiently.
Trust me, not knowing about ecasound internals is not a problem. :)
Basically, if you can come up with a client-side event-interface (in C,
Python, etc), it's then easy for me to implement it in libecasound.
What kind of events would be most useful to the clients? Another
thing is accessing the events. There could be more, but these two are
probably the most common approaches:
a) callback functions (easy in C, maybe in Python; in my personal
opinion, can be messy)
b) UNIX style select/poll approach
A short example using (b):
--cut--
# register a new event - event is produced whenever
# engine state changes (running -> finished; not running -> running, etc)
eci_command("event-add-engine-state")
eci_command("start")
# start waiting for events
eci_poll()
# we get here only if an event has occured
# the next step is to get number of events available
a = eci_events()
while (a > 0)
# get (and remove) the next available event
b = eci_pop_event()
print b
--cut--
Ok, you get the picture. But the important question remains: what kind of
events are really needed?
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/aivastus ... [ aivastus net radio ] /\ .-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Fri Dec 01 2000 - 05:09:05 EET