jack_frame_time() overflow?

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

jack_frame_time() overflow?

Dave Robillard
Hi all,

I'm curious what happens when jack_frame_time() hits the upper limit of
the unsigned int it lives in.. I'm using these timestamps in various
places with absolutely no thought about what happens when it
overflows/wraps/whatever.

I guess people probably don't run Jack for 12 hours straight very often,
but they should be able to.  What happens?

Cheers,

-DR-



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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: jack_frame_time() overflow?

dmmcintyr (Bugzilla)
On Wednesday 03 August 2005 01:56 am, Dave Robillard wrote:

> I guess people probably don't run Jack for 12 hours straight very often,
> but they should be able to.  What happens?

I'm not a JACK developer, and know diddly about its API or its internals, but
I can offer anecdotal evidence from userland that apparently nothing happens.  
I do run JACK for days on end, with things connected to it the whole time.

--
Michael McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621
http://www.geocities.com/Paris/Rue/5407/
http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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: jack_frame_time() overflow?

deviant
In reply to this post by Dave Robillard
it wraps.

as long as you use an unsigned int anywhere you wish to store a return
value from that call, with careful programming you will be fine. for
example if you are using it to try to detect when more than one buffers
worth of sample time has passed, this:

if(old_frame_time + nframes < new_frame_time)

could get screwed up when the buffer wraps. this:

if(new_frame_time - old_frame_time > nframes)

will not, because the subtraction will also wrap.

it is worth noting that the reference for the function states that no
significance should be attached to the return value of
jack_frame_time(), as it is a running counter. so, conceivably, when
your client joins the graph, the value might be about to wrap very soon,
so handling this case is important.

ian

ps: apologies if this mail comes through more than once - i'm having email
problems!


> Hi all,
>
> I'm curious what happens when jack_frame_time() hits the upper limit of
> the unsigned int it lives in.. I'm using these timestamps in various
> places with absolutely no thought about what happens when it
> overflows/wraps/whatever.
>
> I guess people probably don't run Jack for 12 hours straight very often,
> but they should be able to.  What happens?
>
> Cheers,
>
> -DR-
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
>
>




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&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: jack_frame_time() overflow?

Conrad Parker
On Wed, Aug 03, 2005 at 07:56:17AM +0100, [hidden email] wrote:

> it wraps.
>
> as long as you use an unsigned int anywhere you wish to store a return
> value from that call, with careful programming you will be fine. for
> example if you are using it to try to detect when more than one buffers
> worth of sample time has passed, this:
>
> if(old_frame_time + nframes < new_frame_time)
>
> could get screwed up when the buffer wraps. this:
>
> if(new_frame_time - old_frame_time > nframes)
>
> will not, because the subtraction will also wrap.
>
> it is worth noting that the reference for the function states that no
> significance should be attached to the return value of
> jack_frame_time(), as it is a running counter. so, conceivably, when
> your client joins the graph, the value might be about to wrap very soon,
> so handling this case is important.

In that case a jackd option to start with the counter very near
wraparound would make it possible to test applications without
having to wait 12 hours.

For properly nasty testing, jackd should always start about 3 seconds
before wraparound :)

cheers,

Conrad.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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: jack_frame_time() overflow?

Jack O'Quin-2
Conrad Parker <[hidden email]> writes:

> In that case a jackd option to start with the counter very near
> wraparound would make it possible to test applications without
> having to wait 12 hours.
>
> For properly nasty testing, jackd should always start about 3 seconds
> before wraparound :)

Good idea.  A patch to add this option would be nice.
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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: jack_frame_time() overflow?

Dave Robillard
On Wed, 2005-03-08 at 11:22 -0500, Jack O'Quin wrote:

> Conrad Parker <[hidden email]> writes:
>
> > In that case a jackd option to start with the counter very near
> > wraparound would make it possible to test applications without
> > having to wait 12 hours.
> >
> > For properly nasty testing, jackd should always start about 3 seconds
> > before wraparound :)
>
> Good idea.  A patch to add this option would be nice.

++votes

-DR-



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack_frame_time() overflow?

Paul Davis
On Thu, 2005-08-04 at 12:34 +1000, Dave Robillard wrote:

> On Wed, 2005-03-08 at 11:22 -0500, Jack O'Quin wrote:
> > Conrad Parker <[hidden email]> writes:
> >
> > > In that case a jackd option to start with the counter very near
> > > wraparound would make it possible to test applications without
> > > having to wait 12 hours.
> > >
> > > For properly nasty testing, jackd should always start about 3 seconds
> > > before wraparound :)
> >
> > Good idea.  A patch to add this option would be nice.
>
> ++votes

implemented. will commit tomorrow.

there is also a nasty issue with processor type detection & compiler
flags for optimization. we use the compiler abilities, not the processor
abilities. nice for people building packages, not nice for regular
mortals. solutions under consideration. right now, gcc3.X on a celeron
will cause compilation to use SSE instructions, creating an instant
crash at jack startup.

--p




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: jack_frame_time() overflow?

Jussi Laako
On Wed, 2005-08-03 at 22:48 -0400, Paul Davis wrote:

> there is also a nasty issue with processor type detection & compiler
> flags for optimization. we use the compiler abilities, not the processor
> abilities. nice for people building packages, not nice for regular
> mortals. solutions under consideration. right now, gcc3.X on a celeron
> will cause compilation to use SSE instructions, creating an instant
> crash at jack startup.

You probably mean PIII Celeron here? As the P4-based Celerons do have
SSE2 and the newest ones even SSE3.

Would the attached codes help on this at all? I probably made those a
while back for use with jack... Lacks SSE3 detection, but that's easy to
add if those are useful.

Runtime selected (based on cpu detected) asm would be the best solution,
IMO.


--
Jussi Laako <[hidden email]>

test-3dnow.c (697 bytes) Download Attachment
test-sse.c (571 bytes) Download Attachment