Hi Joel,
On Mon, 21 Dec 2015, Joel Roth wrote:
> I know that Ecasound is being maintained, and that
> development has slowed a bit in recent years.
that "a bit" is a slight understatement. :) But yeah, still around.
> I'm wondering if there is any possibility to introduce
> minimal support for the JACK latency API.
Thanks for the write-up. Drafting potential ECI commands is a really good
way to draft the ideas (often big part of the overall effort).
The stateful "update-flag" is a bit new concept, but not totally new as
there have been some stateful counters and flags (e.g. "-ev" and "-evp").
A big challenge is that JACK does expect the latencies to be updated
_within_ the latency callback. E.g. the latency changes come in two steps,
first JACK clients get a callback for JackPlaybackLatency (latency of
feeding input ports may have chaneged) and later for JackCapatureLatency
(fed output ports may have changed). In both, the client is expected to
call jack_port_set_latency_range() within the callback (see jack.h header
docs).
Have to think about this some more, but it may be that more of the logic
has to be done in the ecasound JACK client code directly, but this is
tricky. The port latencies could be exposed via ECI commands.
Do you see problems for Nama in this approach? Is there sources of
latencies Nama would know, but ecasound engine would not...?
------------------------------------------------------------------------------
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sun Jan 3 04:15:03 2016
This archive was generated by hypermail 2.1.8 : Sun Jan 03 2016 - 04:15:03 EET