Tell the Jack server to call @a latency_callback whenever it
is necessary to recompute the latencies for some or all
Jack ports.
@a latency_callback will be called twice each time it is
needed, once being passed JackCaptureLatency and once
JackPlaybackLatency. See @ref LatencyFunctions for
the definition of each type of latency and related functions.
<b>IMPORTANT: Most JACK clients do NOT need to register a latency
callback.</b>
Clients that meet any of the following conditions do NOT
need to register a latency callback:
- have only input ports
- have only output ports
- their output is totally unrelated to their input
- their output is not delayed relative to their input
(i.e. data that arrives in a given process()
callback is processed and output again in the
same callback)
Clients NOT registering a latency callback MUST also
satisfy this condition:
- have no multiple distinct internal signal pathways
This means that if your client has more than 1 input and
output port, and considers them always "correlated"
(e.g. as a stereo pair), then there is only 1 (e.g. stereo)
signal pathway through the client. This would be true,
for example, of a stereo FX rack client that has a
left/right input pair and a left/right output pair.
However, this is somewhat a matter of perspective. The
same FX rack client could be connected so that its
two input ports were connected to entirely separate
sources. Under these conditions, the fact that the client
does not register a latency callback MAY result
in port latency values being incorrect.
Clients that do not meet any of those conditions SHOULD
register a latency callback.
See the documentation for @ref jack_port_set_latency_range()
on how the callback should operate. Remember that the @a mode
argument given to the latency callback will need to be
passed into @ref jack_port_set_latency_range()
@return 0 on success, otherwise a non-zero error code
Tell the Jack server to call @a latency_callback whenever it is necessary to recompute the latencies for some or all Jack ports.
@a latency_callback will be called twice each time it is needed, once being passed JackCaptureLatency and once JackPlaybackLatency. See @ref LatencyFunctions for the definition of each type of latency and related functions.
<b>IMPORTANT: Most JACK clients do NOT need to register a latency callback.</b>
Clients that meet any of the following conditions do NOT need to register a latency callback:
- have only input ports - have only output ports - their output is totally unrelated to their input - their output is not delayed relative to their input (i.e. data that arrives in a given process() callback is processed and output again in the same callback)
Clients NOT registering a latency callback MUST also satisfy this condition:
- have no multiple distinct internal signal pathways
This means that if your client has more than 1 input and output port, and considers them always "correlated" (e.g. as a stereo pair), then there is only 1 (e.g. stereo) signal pathway through the client. This would be true, for example, of a stereo FX rack client that has a left/right input pair and a left/right output pair.
However, this is somewhat a matter of perspective. The same FX rack client could be connected so that its two input ports were connected to entirely separate sources. Under these conditions, the fact that the client does not register a latency callback MAY result in port latency values being incorrect.
Clients that do not meet any of those conditions SHOULD register a latency callback.
See the documentation for @ref jack_port_set_latency_range() on how the callback should operate. Remember that the @a mode argument given to the latency callback will need to be passed into @ref jack_port_set_latency_range()
@return 0 on success, otherwise a non-zero error code