Re: [Jack-Devel] jack_frames_to_time() bug
Le 3 janv. 2012 à 13:04, Fons Adriaensen a écrit :
> On Tue, Jan 03, 2012 at 10:30:18AM +0100, Stéphane Letz wrote:
>
>> I suggest that you prepare a clean patch with all
>> you proposed "timing related changes" (for jack1
>> for instance)
>
> I'd be happy to, provided someone can tell me _which_ changes
> are wanted.
>
> 1. Add the functions to read current and next wakeup times
> separately, fix jack_frames_to_time().
>
> Options in that case:
>
> A. Change the jack_nframes_t parameter or result of jack_frame_time(),
> jack_frames_since_cycle_start(), jack_frames_to_time() and
> jack_time_to_frames() to a double to preserve full precision.
We cannot change current API...
>
> B. Or add new versions keeping the current ones as deprecated.
Possibly.
>
> C. Fix the anomaly in jack_frames_since_cylce_start() which
> seems to use an unfiltered current_wakeup time, making
> it inconsistent with the rest of the timing functions.
OK.
>
> or
>
> 2. Add an atomic accessor for all four of current_wakeup_time,
> next_wakeup_time, last_frame_time, and the current period
> time estimate of the DLL. This allows the client to do all
> calculations to full precision. Leave the other functions as
> the are as a client wanting full precision is not required
> to use them. Of course still fix jack_frames_to_time().
>
> Options in that case:
>
> A. Same as C above.
>
> As a separate but related issue I'd like to review the DLL
> code as I'm not convinced that the current implementation
> provides full precision.
This would be helpful.
>
> AFAIK, the decision is postponed until after the 'great
> unification', so I'm not really motivated to write a patch
> ATM.
Well not sure the 'great unification' will happen before physicists fix the issue on their side... ((-; maybe the discovery of Higgs boson will help?
> OTOH, fixing the bug in jack_frames_to_time() just requires
> a cut-and-paste of three lines (and testing it of course).
> You don't need a patch to do that.
>
> Ciao,
>
> --
Waiting for Paul answer on the whole issue.
Stephane
1325628273.17154_0.ltw:2,a <F89404B4-5B69-4E65-828E-8AC32C6F78BC at grame dot fr>