API: Allow caching for output ports

[twischer-adit]

This commit reverts 3d97601 ("More documentation in jack.h") partly.

The following call stack is used:
jack_port_get_buffer()
JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t)
JackGraphManager::GetBuffer(jack_port_id_t)
JackPort::GetBuffer()

To call JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t)
the object JackLibGlobals::fGlobals->fGraphManage is used. It is only
set in JackLibClient::Open(). Therefore it is not changed in the life
time of a JACK client.

In case port->fTied will be modified at runtime the returned audio
buffer would change. This variable can only be modified by the
deprecated jack_port_tie() function. Therefore as long as not calling
this deprecated function the audio buffer would not change.

The previous analyses is only valid for JACK audio output ports
(JackPortIsOutput). The creating JACK client can write to those
ports. For JACK audio input ports (JackPortIsInput) it is still not
allowed to cache the audio buffer address because for those ports the
returned audio buffer is depending on the port connections
(pipelining). The decision for the pipelining is done in
JackGraphManager::GetBuffer(jack_port_id_t, jack_nframes_t).

[twischer-adit]

Hello @sletz,
sorry for pinging you directly, but it looks like you are the originator of 3d97601. Therefore I think it would be quite beneficial when you could give your feedback why the following sentences were added.

Caching output ports is DEPRECATED in Jack 2.0, due to some new optimization (like "pipelining").
Port buffers have to be retrieved in each callback for proper functionning.

Is there a misunderstanding in the comment or is it even for JACK2 not required and caching output ports is with the already mentioned limitations still allowed?

[falkTX]

The caching is not mentioned in the jack1 headers at https://github.com/jackaudio/headers/blob/master/jack.h#L643
It does seem safe to cache the output buffers (assuming buffer-size callback is in place).
@sletz any comments on this?

[sletz]

This "pipelining" experimental development was actually never merged, so yes caching for output ports is safe.

[falkTX]

Alright, thanks!

[falkTX]

@twischer-adit can you add a note about port-tie? It is a deprecated API, but only because it ended up not being used by client applications. as far as I know, ladish is the only one that uses it

also, should be noted that this is a jack2-specific behaviour.
@wtay is it safe to cache output port buffers under pipewire-jack too?

[twischer]

Hi @falkTX,

can you add a note about port-tie?

Should I add the corresponding commit description as a comment into the source code

In case port->fTied will be modified at runtime the returned audio
buffer would change. This variable can only be modified by the
deprecated jack_port_tie() function. Therefore as long as not calling
this deprecated function the audio buffer would not change.

also, should be noted that this is a jack2-specific behaviour.

As far as I understand it is also allowed to cache the output port with JACK1. Therefore what do you mean special for JACK2

[wtay]

On Sun, 11 Oct 2020 at 23:29, Filipe Coelho ***@***.***> wrote: @twischer-adit <https://github.com/twischer-adit> can you add a note about port-tie? It is a deprecated API, but only because it ended up not being used by client applications. as far as I know, ladish is the only one that uses it also, should be noted that this is a jack2-specific behaviour. @wtay <https://github.com/wtay> is it safe to cache output port buffers under pipewire-jack too?

In general no, the buffer memory can change due to reconnections, latency changes or even when more than 1 buffer is used between ports. However... I've added a hack in PipeWire to detect and handle some cases (calfjackhost). Usually the caching is done outside of the processing loop with jack_port_get_buffer() with a 0 frames argument. If that is the case, I give a fixed area to the client that never changes and copy the samples to the real output buffer after calling the process callback. Wim

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#602 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADUBCRX2BNGPYAHDQMODL53SKIPU3ANCNFSM4OIMBJIA> .