P3 Timer Record cannot maintain scheduled duration if system clock changes

52 messages Options
Embed this post
Permalink
1 2 3
Ed Musgrove-2

P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
---------------from Wiki Release Checklist---------------
GA: Schedule a five minute recording for immediate start (start time
immaterial), OK, then change system clock to one minute before end of
recording. Elapsed time and remaining time will jump to reflect changed
system time, and recording will end having produced just over one minute of
recording.
Schedule that recording exactly the same and change system time to one
minute after the end of the recording. With 1.3.8 Alpha from 04 June 09,
recording will cease immediately, having produced a few seconds of
recording. In a previous test of 1.3.8 Alpha from 29 April 09, an hour long
recording straddling midnight had its elapsed and remaining times frozen
when system clock changed to after end of recording, and carried on after
originally intended duration, but could be cancelled. Repeating that same
hour long test straddling midnight in 04 June 09 build simply aborts
recording when time changes, yet Timer Record code did not change between
those dates.
Are these fixable by relying on a Widgets timer for duration? Many people
synchronize system time to online atomic clocks (Windows XP does it by
default).
---------------------------------------------------------------

Has this been looked at? Here are the obvious problem cases which I can
imagine (what others might there be?):
*If time is now 0100; set recorder to start at 01: 05 and end at 01: 10; set
system time to 01:09:30
-> expected result: thirty second recording starting immediately
*If time is now 01:00; set to start at 01:05 and end at 01:10; set system
time to 01: 11
-> expected result: no recording
*if time is now 23: 50; set recorder to start at 23:55 and end at 01:10
-> expected result: 15 minute recording starting just before midnight

"had its elapsed and remaining times frozen when system clock changed to
after end of recording, and carried on after originally intended duration,
but could be cancelled...that same hour long test straddling midnight in 04
June 09 build simply aborts recording when time changes"

I'm not sure exactly what the above sentence means. It is over 50 minutes
until midnight so I will play around with timed recording for a few minutes
and see what happens...

--Ed




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
Has anyone tested the timed record on 1.3.10?  I just grabbed the CVS Head
and built the debug version.  I tried repeatedly to record some short
segments using the timed record feature.  Except for one 10 second
recording, Audacity crashed every single time.

Using the 29 August build of 1.3.9 downloaded from the Audacity website I
have no trouble making timed recordings.

--Ed


> -----Original Message-----
> From: Ed Musgrove [mailto:[hidden email]]
>
> ---------------from Wiki Release Checklist---------------
> GA: Schedule a five minute recording ...



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Gale (Audacity Team)

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink

| From "Ed Musgrove" <[hidden email]>
| Tue, 13 Oct 2009 23:57:49 -0700
| Subject: [Audacity-devel] P3 Timer Record cannot maintain scheduled duration if system clock changes
> Has anyone tested the timed record on 1.3.10?  I just grabbed the CVS Head
> and built the debug version.  I tried repeatedly to record some short
> segments using the timed record feature.  Except for one 10 second
> recording, Audacity crashed every single time.
>
> Using the 29 August build of 1.3.9 downloaded from the Audacity website I
> have no trouble making timed recordings.

Quick answer, no on Windows XP Timer Record is not crashing for me
if I just start it and hit OK for an immediate five minute recording.
Are you/have you been playing with the system clock to test the P3
issue where the clock changes during recording?

If that's not the reason, can you give some example wait and scheduled
times that crash?



Gale



>
> --Ed
>
>
> > -----Original Message-----
> > From: Ed Musgrove [mailto:[hidden email]]
> >
> > ---------------from Wiki Release Checklist---------------
> > GA: Schedule a five minute recording ...
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
I have determined the source of the problem. This is 100% reproducible here
on Vista (it does not happen unless you change the recording time from five
minutes starting immediately--i.e. simply clicking OK and accepting the
default); steps to reproduce:
*set start timer for 30 seconds after current time
*using either the duration or the end timer set a record time of something
short -- 10 to 15 seconds
*click OK to start the "wait for start" dialogue

 It's not actually an "Crash" it is a wxASSERT which is being called because
of a divide by zero error:

At the end of the short recording the following assert presents:

d:\audio\Audacity\timed record\audacity\src\widgets\ProgressDialog.cpp line
1417 & 1418:
int nGaugeValue = (1000 * elapsed) / mDuration; // range = [0,1000]
   wxASSERT((nGaugeValue >= 0) && (nGaugeValue <= 1000));

Given that this is timer code which is exercised constantly, I could not use
breakpoints and stepping so I fell back on the good old printf...

   int nGaugeValue = (1000 * elapsed) / mDuration; // range = [0,1000]
                                                                        if
(nGaugeValue > 1000)
                                                                        {
 
wxString gv;
 
gv.Printf("gv is %d", nGaugeValue);
 
wxMessageBox(gv.c_str());
 
gv.Printf("elapsed = %d, mDur = %d", elapsed, mDuration);
 
wxMessageBox(gv.c_str());
                                                                        }
   wxASSERT((nGaugeValue >= 0) && (nGaugeValue <= 1000));

nGaugeValue = 1020 +- 10
mDuration = 0
ergo div by 0

BTW, just to insure that I was not having a collision with Dragon
NaturallySpeaking, I exited it for the tests. I performed the "default five
minute" test three separate times successfully. I have not looked into the
details but it would appear that something is going wrong using the
"duration" setting -- if it is changed with any method the problem appears.
I just did a 6 minute test changing only the duration and starting
immediately and got the assert.


--Ed

> -----Original Message-----
> From: Gale Andrews [mailto:[hidden email]]
> Sent: Wednesday, October 14, 2009 2:18 AM
> To: [hidden email]
> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> duration if system clock changes
>
>
> | From "Ed Musgrove" <[hidden email]> Tue, 13 Oct 2009
> | 23:57:49 -0700
> | Subject: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> duration if system clock changes
> > Has anyone tested the timed record on 1.3.10?  I just grabbed the CVS
> > Head and built the debug version.  I tried repeatedly to record some
> > short segments using the timed record feature.  Except for one 10
> > second recording, Audacity crashed every single time.
> >
> > Using the 29 August build of 1.3.9 downloaded from the Audacity
> > website I have no trouble making timed recordings.
>
> Quick answer, no on Windows XP Timer Record is not crashing for me if I
just

> start it and hit OK for an immediate five minute recording.
> Are you/have you been playing with the system clock to test the P3 issue
> where the clock changes during recording?
>
> If that's not the reason, can you give some example wait and scheduled
> times that crash?
>
>
>
> Gale
>
>
>
> >
> > --Ed
> >
> >
> > > -----Original Message-----
> > > From: Ed Musgrove [mailto:[hidden email]]
> > >
> > > ---------------from Wiki Release Checklist---------------
> > > GA: Schedule a five minute recording ...
> >
> >
> >
> >
----------------------------------------------------------------------------
--
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and
stay

> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Al Dimond

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
On Wednesday 14 October 2009 11:43:52 Ed Musgrove wrote:

> I have determined the source of the problem. This is 100% reproducible here
> on Vista (it does not happen unless you change the recording time from five
> minutes starting immediately--i.e. simply clicking OK and accepting the
> default); steps to reproduce:
> *set start timer for 30 seconds after current time
> *using either the duration or the end timer set a record time of something
> short -- 10 to 15 seconds
> *click OK to start the "wait for start" dialogue
>
>  It's not actually an "Crash" it is a wxASSERT which is being called
>  because of a divide by zero error:
>

I'm seeing the same thing here on Linux.

> At the end of the short recording the following assert presents:
>
> d:\audio\Audacity\timed record\audacity\src\widgets\ProgressDialog.cpp line
> 1417 & 1418:
> int nGaugeValue = (1000 * elapsed) / mDuration; // range = [0,1000]
>    wxASSERT((nGaugeValue >= 0) && (nGaugeValue <= 1000));
>
> Given that this is timer code which is exercised constantly, I could not
>  use breakpoints and stepping so I fell back on the good old printf...
>
>    int nGaugeValue = (1000 * elapsed) / mDuration; // range = [0,1000]
>                                                                         if
> (nGaugeValue > 1000)
>                                                                         {
>
> wxString gv;
>
> gv.Printf("gv is %d", nGaugeValue);
>
> wxMessageBox(gv.c_str());
>
> gv.Printf("elapsed = %d, mDur = %d", elapsed, mDuration);
>
> wxMessageBox(gv.c_str());
>                                                                         }
>    wxASSERT((nGaugeValue >= 0) && (nGaugeValue <= 1000));
>
> nGaugeValue = 1020 +- 10
> mDuration = 0
> ergo div by 0
>

The assertion is not testing the divide by zero, and mDuration probably isn't
zero, for that matter.  Your printf is using %d and mDuration is a wxLongLong.  
nGagueValue never would have been set to ~1020 if mDuration was actually zero.  
The assertion is hit because (elapsed > mDuration), which causes (1000 *
elapsed / mDuration) to be larger than 1000.  So the question is what allows
elapsed to get that large.

> BTW, just to insure that I was not having a collision with Dragon
> NaturallySpeaking, I exited it for the tests. I performed the "default five
> minute" test three separate times successfully. I have not looked into the
> details but it would appear that something is going wrong using the
> "duration" setting -- if it is changed with any method the problem appears.
> I just did a 6 minute test changing only the duration and starting
> immediately and got the assert.
>
>
> --Ed
>
> > -----Original Message-----
> > From: Gale Andrews [mailto:[hidden email]]
> > Sent: Wednesday, October 14, 2009 2:18 AM
> > To: [hidden email]
> > Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> > duration if system clock changes
> >
> > | From "Ed Musgrove" <[hidden email]> Tue, 13 Oct 2009
> > | 23:57:49 -0700
> > | Subject: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> >
> > duration if system clock changes
> >
> > > Has anyone tested the timed record on 1.3.10?  I just grabbed the CVS
> > > Head and built the debug version.  I tried repeatedly to record some
> > > short segments using the timed record feature.  Except for one 10
> > > second recording, Audacity crashed every single time.
> > >
> > > Using the 29 August build of 1.3.9 downloaded from the Audacity
> > > website I have no trouble making timed recordings.
> >
> > Quick answer, no on Windows XP Timer Record is not crashing for me if I
>
> just
>
> > start it and hit OK for an immediate five minute recording.
> > Are you/have you been playing with the system clock to test the P3 issue
> > where the clock changes during recording?
> >
> > If that's not the reason, can you give some example wait and scheduled
> > times that crash?
> >
> >
> >
> > Gale
> >
> > > --Ed
> > >
> > > > -----Original Message-----
> > > > From: Ed Musgrove [mailto:[hidden email]]
> > > >
> > > > ---------------from Wiki Release Checklist---------------
> > > > GA: Schedule a five minute recording ...
>
> ---------------------------------------------------------------------------
> - --
>
> > > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > > is the only developer event you need to attend this year. Jumpstart
> > > your developing skills, take BlackBerry mobile applications to market
> > > and
>
> stay
>
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > > http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > audacity-devel mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ---------------------------------------------------------------------------
> - --
>
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ---------------------------------------------------------------------------
> --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
>  the only developer event you need to attend this year. Jumpstart your
>  developing skills, take BlackBerry mobile applications to market and stay
>  ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>  http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
"Your printf is using %d and mDuration is a wxLongLong."

For a wxLongLong I will use the built-in ToString. printf 101 was a very
long time ago for me (and I think I flunked that class)!

"So the question is what allows elapsed to get that large."

I will try to look into that tonight.

--Ed


> -----Original Message-----
> From: Al Dimond [mailto:[hidden email]]
>
> >  It's not actually an "Crash" it is a wxASSERT which is being called
> > because of a divide by zero error:
> >
>
> I'm seeing the same thing here on Linux.
>
[...]
> > gv.Printf("elapsed = %d, mDur = %d", elapsed, mDuration);
[...]
> > mDuration = 0
> > ergo div by 0
> >
>
> The assertion is not testing the divide by zero, and mDuration probably
isn't
> zero, for that matter.  Your printf is using %d and mDuration is a
wxLongLong.
> nGagueValue never would have been set to ~1020 if mDuration was actually
> zero.
> The assertion is hit because (elapsed > mDuration), which causes (1000 *
> elapsed / mDuration) to be larger than 1000.  So the question is what
allows
> elapsed to get that large.



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Martyn Shaw-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
wxLongLong thingy = 100;
printf("thingy %lld", thingy);
worked for me.

Martyn

Ed Musgrove wrote:

> "Your printf is using %d and mDuration is a wxLongLong."
>
> For a wxLongLong I will use the built-in ToString. printf 101 was a very
> long time ago for me (and I think I flunked that class)!
>
> "So the question is what allows elapsed to get that large."
>
> I will try to look into that tonight.
>
> --Ed
>
>
>> -----Original Message-----
>> From: Al Dimond [mailto:[hidden email]]
>>
>>>  It's not actually an "Crash" it is a wxASSERT which is being called
>>> because of a divide by zero error:
>>>
>> I'm seeing the same thing here on Linux.
>>
> [...]
>>> gv.Printf("elapsed = %d, mDur = %d", elapsed, mDuration);
> [...]
>>> mDuration = 0
>>> ergo div by 0
>>>
>> The assertion is not testing the divide by zero, and mDuration probably
> isn't
>> zero, for that matter.  Your printf is using %d and mDuration is a
> wxLongLong.
>> nGagueValue never would have been set to ~1020 if mDuration was actually
>> zero.
>> The assertion is hit because (elapsed > mDuration), which causes (1000 *
>> elapsed / mDuration) to be larger than 1000.  So the question is what
> allows
>> elapsed to get that large.
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
> printf("thingy %lld", thingy);

Great! I had recalled ldd but knew it did not look right. I have the Sam's
teach yourself C++ 2008 version which does not cover any of the 64-bit
parameters for printf.

The real question as Al put it:
> >> The assertion is hit because (elapsed > mDuration), which causes
> >> (1000 * elapsed / mDuration) to be larger than 1000.  So the question
> >> is what allows elapsed to get that large.

I am guessing that the August 29 build that I downloaded as executable code
was a Release version not Debug version. The assert is only exposed in the
Debug version.

wxLongLong_t now = wxGetLocalTimeMillis().GetValue();
wxLongLong_t elapsed = now - mStartTime;
wxLongLong_t remains = mStartTime + mDuration - now;

Eventually, "remains" becomes a negative value. Using any method other than
conditional printfs will mask the problem because the timer continues
running. This is either trivial, and a test for "remains less than zero"
should mask the assert or else we really are recording ever so slightly past
duration. I hate spin my wheels looking into this to simply write it off as
a learning experience-- if someone knows what's going on here please chime
in!

--Ed


> -----Original Message-----
> From: Martyn Shaw [mailto:[hidden email]]
> Sent: Wednesday, October 14, 2009 5:18 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> duration if system clock changes
>
> wxLongLong thingy = 100;
> printf("thingy %lld", thingy);
> worked for me.
>
> Martyn
>
> Ed Musgrove wrote:
> > "Your printf is using %d and mDuration is a wxLongLong."
> >
> > For a wxLongLong I will use the built-in ToString. printf 101 was a
> > very long time ago for me (and I think I flunked that class)!
> >
> > "So the question is what allows elapsed to get that large."
> >
> > I will try to look into that tonight.
> >
> > --Ed
> >
> >
> >> -----Original Message-----
> >> From: Al Dimond [mailto:[hidden email]]
> >>
> >>>  It's not actually an "Crash" it is a wxASSERT which is being called
> >>> because of a divide by zero error:
> >>>
> >> I'm seeing the same thing here on Linux.
> >>
> > [...]
> >>> gv.Printf("elapsed = %d, mDur = %d", elapsed, mDuration);
> > [...]
> >>> mDuration = 0
> >>> ergo div by 0
> >>>
> >> The assertion is not testing the divide by zero, and mDuration
> >> probably
> > isn't
> >> zero, for that matter.  Your printf is using %d and mDuration is a
> > wxLongLong.
> >> nGagueValue never would have been set to ~1020 if mDuration was
> >> actually zero.
> >> The assertion is hit because (elapsed > mDuration), which causes
> >> (1000 * elapsed / mDuration) to be larger than 1000.  So the question
> >> is what
> > allows
> >> elapsed to get that large.
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- Come build with us! The BlackBerry(R) Developer Conference in
> > SF, CA is the only developer event you need to attend this year.
> > Jumpstart your developing skills, take BlackBerry mobile applications
> > to market and stay ahead of the curve. Join us from November 9 - 12,
> > 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
>
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the
> only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Martyn Shaw-2
I commented out the assert. After changing the duration to anything other
than the default five minutes,  the resulting recording is longer than the
requested duration; a 3 second recording is 3.1.4 seconds, an 8 second
recording is 8.25 seconds long. Is this expected behavior, does anyone care?

--Ed




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In fact, even with the default five minute recording the recording is
noticeably longer than exactly 5 minutes.

--Ed

> -----Original Message-----
> From: Ed Musgrove [mailto:[hidden email]]
> Sent: Wednesday, October 14, 2009 9:25 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> duration if system clock changes
>
> I commented out the assert. After changing the duration to anything other
> than the default five minutes,  the resulting recording is longer than the
> requested duration; a 3 second recording is 3.1.4 seconds, an 8 second
> recording is 8.25 seconds long. Is this expected behavior, does anyone
care?
>
> --Ed
>
>
>
>
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the
> only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
These two changes solve the problem I stumbled onto just trying to figure
out what the original bug was...

In file ProgressDialog.cpp near line 1412:
int TimerProgressDialog::Update(const wxString & message /*=
wxEmptyString*/)
{
   [...]
   wxLongLong_t remains = mStartTime + mDuration - now;

   if (remains <= 0) {return eProgressSuccess;}   //  add this line

   if (!IsShown() && elapsed > 500)
   [...]
   wxASSERT((nGaugeValue >= 0) && (nGaugeValue <= 1000));

In file TimerRecordDialog.cpp near line 47:

//const int kTimerInterval = 500; // every 500 ms => 2 updates per second
const int kTimerInterval = 50; // makes the granularity un-noticeable and
does not affect
                                                           //  performance
on my (fast) Vista machine

--Ed

> -----Original Message-----
> From: Ed Musgrove [mailto:[hidden email]]
>
> Is this expected behavior, does anyone care?



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ed Musgrove-2
Note that elsewhere  kTimerInterval  is #defined and redefined and in both
instances it is "50".


D:\audio\Audacity\timed
record\audacity\src\TimerRecordDialog.cpp(47)://const int kTimerInterval =
500; // every 500 ms => 2 updates per second
  D:\audio\Audacity\timed
record\audacity\src\TimerRecordDialog.cpp(48):const int kTimerInterval = 50;
// every 50 ms => 20 updates per second   /*efm5*/
  D:\audio\Audacity\timed record\audacity\src\TrackPanel.cpp(237):#define
kTimerInterval 50 // milliseconds
  D:\audio\Audacity\timed
record\audacity\src\widgets\ExpandingToolBar.cpp(87):const int
kTimerInterval = 50; // every 50 ms -> ~20 updates per second  

--Ed




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Richard Ash (audacity-help)

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ed Musgrove-2
On Wed, 2009-10-14 at 20:12 -0700, Ed Musgrove wrote:
> > printf("thingy %lld", thingy);
>
> Great! I had recalled ldd but knew it did not look right. I have the Sam's
> teach yourself C++ 2008 version which does not cover any of the 64-bit
> parameters for printf.

http://linux.die.net/man/3/printf

Richard


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
Richard, thank you for the link to the manual page for printf! There is a
lot of new stuff there.

--Ed

> -----Original Message-----
> From: Richard Ash [mailto:[hidden email]]
>
> http://linux.die.net/man/3/printf



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Vaughan Johnson

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ed Musgrove-2


Ed Musgrove wrote:
> ...
> In file TimerRecordDialog.cpp near line 47:
>
> //const int kTimerInterval = 500; // every 500 ms => 2 updates per second
> const int kTimerInterval = 50; // makes the granularity un-noticeable and
> does not affect
>                                                            //  performance
> on my (fast) Vista machine
>
Yes, that's the point. I made it big to accommodate users with slower
machines. But that was then and people have faster machines on average
now, so I committed the change to 50ms. We'll give it a shot and if
users complain about recording issues, revert it.

- Vaughan

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Vaughan Johnson

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ed Musgrove-2


Ed Musgrove wrote:
> Note that elsewhere  kTimerInterval  is #defined and redefined and in both
> instances it is "50".
Yes, but those are local definitions and they're doing different things,
so there's really no reason to expect them to be the same for different
timers.

Nothing breaks if timer record updates 1/10th as frequently and has an
extra half-second or less of recorded result, but TrackPanel updates
would be painfully lagging.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Vaughan Johnson
Hi Vaughan!

The problem I was seeing with its set at five hundred was that recordings
were one quarter of a second per 5 seconds longer than the requested
duration. Setting it down to fifty changes it from one quarter of a second
to a fraction of one hundredth of a second. That seems strange to me,
because it's only the graphic update granularity. It might actually be a
problem with variable masking --const int kTimerInterval is declared three
times in the Audacity source, once at five hundred twice at fifty.

Thanks for your consideration on this!

--Ed


> -----Original Message-----
> From: Vaughan Johnson [mailto:[hidden email]]
> Sent: Saturday, October 17, 2009 3:51 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> duration if system clock changes
>
>
>
> Ed Musgrove wrote:
> > ...
> > In file TimerRecordDialog.cpp near line 47:
> >
> > //const int kTimerInterval = 500; // every 500 ms => 2 updates per
> > second const int kTimerInterval = 50; // makes the granularity
> > un-noticeable and does not affect
> >                                                            //
> > performance on my (fast) Vista machine
> >
> Yes, that's the point. I made it big to accommodate users with slower
> machines. But that was then and people have faster machines on average
> now, so I committed the change to 50ms. We'll give it a shot and if users
> complain about recording issues, revert it.
>
> - Vaughan
>
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the
> only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Ed Musgrove-2

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Vaughan Johnson
Thanks Vaughan for taking the time to explain this to me!

--Ed


> -----Original Message-----
> From: Vaughan Johnson [mailto:[hidden email]]
> Sent: Saturday, October 17, 2009 3:54 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
> duration if system clock changes
>
>
>
> Ed Musgrove wrote:
> > Note that elsewhere  kTimerInterval  is #defined and redefined and in
> > both instances it is "50".
> Yes, but those are local definitions and they're doing different things,
so
> there's really no reason to expect them to be the same for different
timers.
>
> Nothing breaks if timer record updates 1/10th as frequently and has an
extra
> half-second or less of recorded result, but TrackPanel updates would be
> painfully lagging.
>
>
>
----------------------------------------------------------------------------
--
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the
> only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Vaughan Johnson

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ed Musgrove-2
Ed Musgrove wrote:
> Hi Vaughan!
>
> The problem I was seeing with its set at five hundred was that recordings
> were one quarter of a second per 5 seconds longer than the requested
> duration. Setting it down to fifty changes it from one quarter of a second
> to a fraction of one hundredth of a second. That seems strange to me,
> because it's only the graphic update granularity.
No, it isn't just graphic update. It sets bIsRecording each time in that
loop, and when the current time is past the end, it's set false, so
exits the loop, and stops recording. Sleep is not precise, so it will
always be different on different executions. So if the timer interval is
set to 500ms, the worst it can be off is a half second. At 50ms, the
worst it can be off is 1/20 s, but sometimes it will be almost perfect.

Note that the wxTimer m_Timer itself is used only for updating the
dialog if start time is "now" (updating start and end, preserving
duration), but the same interval value is used for the recording
progress loop.

---
It might actually be a
> problem with variable masking --const int kTimerInterval is declared three
> times in the Audacity source, once at five hundred twice at fifty.
As I wrote, those are distinct, local declarations. Debug them with
different values and you'll see.

- Vaughan
===

>
> Thanks for your consideration on this!
>
> --Ed
>
>
>> -----Original Message-----
>> From: Vaughan Johnson [mailto:[hidden email]]
>> Sent: Saturday, October 17, 2009 3:51 PM
>> To: [hidden email]
>> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
>> duration if system clock changes
>>
>>
>>
>> Ed Musgrove wrote:
>>> ...
>>> In file TimerRecordDialog.cpp near line 47:
>>>
>>> //const int kTimerInterval = 500; // every 500 ms => 2 updates per
>>> second const int kTimerInterval = 50; // makes the granularity
>>> un-noticeable and does not affect
>>>                                                            //
>>> performance on my (fast) Vista machine
>>>
>> Yes, that's the point. I made it big to accommodate users with slower
>> machines. But that was then and people have faster machines on average
>> now, so I committed the change to 50ms. We'll give it a shot and if users
>> complain about recording issues, revert it.
>>
>> - Vaughan
>>
>>
> ----------------------------------------------------------------------------
> --
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the
>> only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Vaughan Johnson

Re: P3 Timer Record cannot maintain scheduled duration if system clock changes

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ed Musgrove-2
Sure. Thanks for your interest. - V

Ed Musgrove wrote:

> Thanks Vaughan for taking the time to explain this to me!
>
> --Ed
>
>
>> -----Original Message-----
>> From: Vaughan Johnson [mailto:[hidden email]]
>> Sent: Saturday, October 17, 2009 3:54 PM
>> To: [hidden email]
>> Subject: Re: [Audacity-devel] P3 Timer Record cannot maintain scheduled
>> duration if system clock changes
>>
>>
>>
>> Ed Musgrove wrote:
>>> Note that elsewhere  kTimerInterval  is #defined and redefined and in
>>> both instances it is "50".
>> Yes, but those are local definitions and they're doing different things,
> so
>> there's really no reason to expect them to be the same for different
> timers.
>> Nothing breaks if timer record updates 1/10th as frequently and has an
> extra
>> half-second or less of recorded result, but TrackPanel updates would be
>> painfully lagging.
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the
>> only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
1 2 3