[patch] cap jack_frame_time() result to current period

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch] cap jack_frame_time() result to current period

Florian Paul Schmidt-2

Hi,

even with the new DLL code for jack_frametime, there's still a miniscule
chance of the reported frame_time being either a very few samples
smaller than jack_last_frame_time() or bigger than
jack_last_frame_time()+periodsize().

This patch caps the frametime to the current period (Dunno, whether it's
really necessary or even The Right Thing To Do though):

Index: libjack/transclient.c
===================================================================
RCS file: /cvsroot/jackit/jack/libjack/transclient.c,v
retrieving revision 1.22
diff -u -r1.22 transclient.c
--- libjack/transclient.c 19 Dec 2004 18:41:29 -0000 1.22
+++ libjack/transclient.c 25 Nov 2005 00:07:59 -0000
@@ -236,6 +236,7 @@
 {
  jack_frame_timer_t time;
  jack_control_t *ectl = client->engine;
+ jack_nframes_t ret;
 
  jack_read_frame_time (client, &time);
 
@@ -252,9 +253,19 @@
  (time.next_wakeup - time.current_wakeup)) * ectl->buffer_size));
 #endif
 
- return time.frames +
+ ret = time.frames +
  (long) rint (((double) ((long long) (now - time.current_wakeup))/
  ((long long) (time.next_wakeup - time.current_wakeup))) * ectl->buffer_size);
+
+ /* cap frametime to be inside the current buffer */
+
+ if (ret < time.frames)
+ ret = time.frames;
+
+ if (ret >= time.frames + ectl->buffer_size)
+ ret = time.frames + ectl->buffer_size;
+
+ return ret;
  }
 
  return 0;


Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org

jack_frametime_cap.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [patch] cap jack_frame_time() result to current period

Florian Paul Schmidt-2
On Fri, 25 Nov 2005 10:03:25 +0100
Alfons Adriaensen <[hidden email]> wrote:

> On Fri, Nov 25, 2005 at 01:14:26AM +0100, Florian Schmidt wrote:
>
> > even with the new DLL code for jack_frametime, there's still a miniscule
> > chance of the reported frame_time being either a very few samples
> > smaller than jack_last_frame_time() or bigger than
> > jack_last_frame_time()+periodsize().
> >
> > This patch caps the frametime to the current period (Dunno, whether it's
> > really necessary or even The Right Thing To Do though):
>
> This introduces a non-linear operation that could mess up things for
> clients that do any further filtering. Ergo it should not be done
> inside jack, or at least be an option or a separate function.

I agree. Thanks for your insights :) I'm always able to learn something
from you. Maybe i'll add jack_constrained_frame_time() tonight. Btw:
coming back to your proposal from a while back to add a single function
call to get all timing info. I have to strongly agree with this.
Otherwise all kinds of sync nastyness might show up. But i'm not so much
interested in the internal DLL parameters, but rather an atomic call for
an app to get both frame_time and last_frame_time in a single call.

I might write a small patch tonight for that adding
jack_frame_times(some_yet_be_defined_struct *storage) :) which will
return frame_time, last_frame_time and constrained_frame_time.

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [patch] cap jack_frame_time() result to current period

Florian Paul Schmidt-2
On Fri, 25 Nov 2005 12:19:04 +0100
Florian Schmidt <[hidden email]> wrote:

> I agree. Thanks for your insights :) I'm always able to learn something
> from you. Maybe i'll add jack_constrained_frame_time() tonight. Btw:
> coming back to your proposal from a while back to add a single function
> call to get all timing info. I have to strongly agree with this.
> Otherwise all kinds of sync nastyness might show up. But i'm not so much
> interested in the internal DLL parameters, but rather an atomic call for
> an app to get both frame_time and last_frame_time in a single call.
>
> I might write a small patch tonight for that adding
> jack_frame_times(some_yet_be_defined_struct *storage) :) which will
> return frame_time, last_frame_time and constrained_frame_time.

Bad idea?

Flo

--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [patch] cap jack_frame_time() result to current period

Florian Paul Schmidt-2
On Sat, 26 Nov 2005 12:56:12 +0100
Florian Schmidt <[hidden email]> wrote:

> > I might write a small patch tonight for that adding
> > jack_frame_times(some_yet_be_defined_struct *storage) :) which will
> > return frame_time, last_frame_time and constrained_frame_time.
>
> Bad idea?

Actually i was confused. This wouldn't help. BTW: Fons, do you have a
patch against current CVS to expose the DLL/timing stuff?

Regards,
Flo

--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [patch] cap jack_frame_time() result to current period

Fons Adriaensen
On Tue, Nov 29, 2005 at 07:26:13PM +0100, Florian Schmidt wrote:

> > Bad idea?

No, but we should separate those pieces of information that depend
on "now" and those that are static within any given cycle.

> Actually i was confused. This wouldn't help. BTW: Fons, do you have a
> patch against current CVS to expose the DLL/timing stuff?

Not against current CVS (I'm using 0.100 for daily work now), and not
a patch, but I implemented most of this in the months leading up to
the latest LAC on top of IIRC 0.99.54. The code never reached a state
that made it ready to be submitted as a patch, and it probably was too
ambitious and far-reaching to be accepted, but it worked well, and I
even modified my (then) copy of scsynth to make use of it. It's still
somewhere in my archives, maybe to be revived some day...

What I did was (from memory):

- add a second DLL using gettimeofday() converted to the OSC time
  format (32.32 seconds since 1900). It used the gettimeofday()
  call only about 4 times per second, regardless of period size.

- on the client side, add a call

  jack_get_cycle_timers (jack_cycle_timers_t *)

  that would copy all interesting information frowm both DLLs
  to a client-supplied struct. This was a 'lazy copy', if a
  client would call it twice or more during the same cycle,
  it would do nothing more but check the cycle count. This
  was done by not only comparing the guards at each end to
  each other, but also to those of the copy.
  The reason a opted to use a client-supplied struct was
  to avoid changing any data structures in shared memory,
  as this would mean a new interface version (*).

- all other calls used by the client to obtain any sort
  of timing info used the jack_cycle_timers struct as
  the first argument, and all calculation were done
  using the only info therein. These calls allowed a
  client to obtain:

  - frame time corresponding to start and end of the
    cycle,
  - frame time corresponding to a gettsc() value
  - frame time corresponding to a gettimeofday() value
  - OSC time corresponding to start and end of the
    cycle,
  - OSC time corresponding to a gettsc() value
  - etc, essentially providing all combinations
    just by some client-side calculations based
    on the information in the struct.

- other information was made available, such as the
  measured sample rate (as would be needed by net-
  worked or multi-card extensions).

- compatibility functions based on the above.

Given the recent thread on TSC problems in SMP systems,
using this even to measure small differences looks less
like a good idea than it did at the time. But I don't know
by what it could be replaced.


(*) Actually, would it ? Would there be any problem with
modifying the layout of the data kept in shared memory as
long as the jackd and libjack code are kept in sync, as
would always be the case when both are compiled from the
same version ?
 

--
FA


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel