Re: [ecasound] Feature request: supporting JACK latency API

Hello Kai,

On Sun, Jan 03, 2016, Kai Vehmanen wrote:
> 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...?

One special case would be a hardware insert, where a
signal is routed to a soundcard output, then returns
to the ecasound signal processing network via a soundcard input.

In the diagram below, all identifiers represent ecasound
chains.

--- track ---+-- wet-send wet-return ---+-- successor
             | |
             +----------- dry -------------+

If necessary, Nama could communicate that to ecasound over
the dry signal path using the LADSPA artificial latency
plugin, 1914, a simple pass-through that reports as latency
whatever value is assigned to parameter 1.

Ecasound engine would have to walk through the chain
setup adding up the latencies of each plugin on each chain
that reports it, and propagate that to the output or input
port.

Nama will also iterate over the signal graph, adding actual
delay via LADSPA plugin to equalize latency to the maximum
value found on parallel chains.

In hardware insert scenario, I would think Ecasound should
report the maximum latency found as both min and max
latency.

If a Nama user adds an effect, or adjusts the parameters of
existing effect in a way that might change the latency of a
signal path, Ecasound will need to know to call
jack_recompute_total_latencies().

Or Nama will need to ask Ecasound to do so, or perhaps tell
jackd directly. Dynamic languages such as Perl/Python/Lua
do have access to some JACK API functions via the Jacks
project.

https://github.com/navicore/Jacks

However this doesn't handle the latency callbacks.

Actually, I'm a little foggy how exactly a callback works.
If I understand correctly, a callback is a memory address.
How does one process, jackd, tell another process, ecasound,
to execute a callback?

Regards,

Joel

-- 
Joel Roth
  
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list