Re: [Jack-Devel] Jack's timing functions

On Tue, Dec 27, 2011 at 12:54:22PM +0100, Robin Gareus wrote:
 
> How does it compare to rubberband?

Not at all :-) 

In apps like alsa_in and alsa_out the actual resampling ratio is always
very close to the nominal one, at most plus or minus one percent. So you
can use a fixed multiphase filter and only the rate of change of the
filter phase is modified dynamically to change the effective ratio.

For things like rubberband this is quite different - the range of
resampling ratios can be very wide. As long as you are upsampling the
filter can stay the same (as the output has more bandwidth than the
input). When downsampling this is no longer the case: the filter 
depends on the ratio, unless you use a fixed one corresponding to
the lowest ratio (which means part of the signal is lost even when
that is not necessary).

The problem I've been looking at is a different one. When resampling
between two unrelated clock domains the exact ratio is not know a
priori, it has to be measured by using the period timing (and some
other info) of both sides, and it has to adapt to any slow changes.
The ratio should be nearly constant and change very smoothly to
avoid adding phase noise to the signal. You also want the latency
of the resampled signal to be defined and constant. It's not at all
evident how to this accurately, even without the random errors on the
timing information, Jack skipping a cycle every now and then (e.g.when
new apps are started), and xruns on the ALSA stream. 
 
> unless someone can point out a case for individually querying
> jack_current_wakeup_time() and jack_next_wakeup_time(), your 2nd idea
> seems best:
> 
> int jack_get_cycle_timing (
>   const jack_client_t* client,
>   jack_nframes_t*      last_frame_time,
>   jack_time_t*         current_wakeup_time,
>   jack_time_t*         next_wakeup_time,
> );

I'd have one objection to this: since this interface at least _suggests_ 
that the three values are consistent (i.e. from the same cycle), it 
should probably use the 'guards' as in jack_read_frame_time() to ensure
they are in case it would ever be used from an arbitrary thread instead
of from the process callback. This  means additional overhead and also
depending on a 'disgusting' hack (see comments in jack_read_frame_time).
If a better way would be found to ensure an atomic copy I'd be all for
it. 

> Yet, your first proposal of adding two functions is more conform with
> the existing JACK API.

Yes. I'd also add 

jack_nframes_t jack_current_wakeup_frames(jack_client *client)  

as an alias for jack_last_frame_time() - that function's name is
really rather confusing. 

Ciao,

-- 
FA

Vor uns liegt ein weites Tal, die Sonne scheint - ein Glitzerstrahl.

1324990866.27072_0.ltw:2,a <20111227130056.GA10351 at linuxaudio dot org>