Re: Feature request: supporting JACK latency API

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list