Delay typing into a label or dragging tracks vertically

[waxcylinder]

But note that labelling worked fine and dandy (immediately briskly) in 1.3.12 and previous (and still does - I've tested recently)

What is the build date of your 1.3.12 ( Help > About Audacity ). I will look at the commit log starting with that date and see if I can spot anything which might relate to labels...

Hi Ed,

I can't see a build date in the "About Audacity" - but the the "last modified" date of the EXE file is 29Mar2010

WC

[waxcylinder]

<vulgar explicative> -- SVN only lets me look back a few months. I have no way of digging back into the changes between Jan & Oct 2010.

And that's one of the "unintended consequences" of having such long periods between releases ...

[waxcylinder]

OK, I can now duplicate this problem. I need to have a lot of audio -- it is barely perceptible with 2 hours of mono noise, just noticeable with 3 hrs; with 1 hour I see no problem.

It seems to be worse when zoomed out a long way, which I typically do as I want to see a lot of the project in on go, typically the whole side of an LP - or as I am working with right now about 35 minutes-worth out of a 2-hour stereo show.

[steve]

I can't see a build date in the "About Audacity"

Look at the bottom of the "Build Information" tab. If it's anywhere it will be there. (I think the build date may be not always included on the release version - not sure because I usually build from source).

[waxcylinder]

I can't see a build date in the "About Audacity"

Look at the bottom of the "Build Information" tab. If it's anywhere it will be there. (I think the build date may be not always included on the release version - not sure because I usually build from source).

Yup, your right - it says: Mar 29 2010

Previously, I must have just had a "man look" as female friends chided me onetime

[Irish]

I've tested the delay typing in a label with 1.13.12 Beta (Mar 29 2010), 1.3.13 Alpha (Feb 28 2011) and 1.3.13 Beta, on two different Windows machines running XP and Win 7, using the same audio.

Machine 1.
Dell Optiplex 755 desktop,
Intel Core2 Duo CPU 3GHz,
1.95GB ram,
Windows XP-Pro SP3,
75GB HD, 54GB free.

Machine 2.
Dell Latitude D630 laptop,
Intel Core2 Duo CPU 2.4GHz,
2.0GB RAM,
Windows 7 Enterprise
75GB HD, 41GB free.

XP machine with 1.3.13 Beta
Imported a 50 minute 44.1kHz stereo WAV.
Typing nonsense in a label as fast as I can. - significant delay between stopping typing and text being displayed (100 characters took approx 10 seconds to display. Fewer characters took proportionately less time).

Same test with a 2 minute 44.1kHz stereo WAV - almost instant response.

XP machine with 1.3.13 Alpha
Same tests as with 1.3.13. Beta - same result

In either case, being zoomed in or out didn't appear to have a significant effect on the result.

XP machine with 1.3.12 Beta
Screen display follows the typing instantly, no matter how fast I type.


The effect seems much worse on the Win 7 machine:

Win 7 Machine with 1.3.13 Beta
Same tests as on the XP machine - 100 chars took almost 30 seconds to display.
With 2 minute show - almost instant response

Win 7 Machine with 1.3.13 Alpha
Same tests as with 1.3.13 Beta - same result

Win 7 Machine with 1.3.12 Beta
Instant response.

POL

[Edgar]

I'm surprised that Gale has not chimed in yet but from what I see he has been extremely busy updating Bugzilla preparing for Release Notes.

After all this I think we can all agree that there is a regression here; whether it is bad enough to be called a bug is the question. Since none of us is a Developer Programmer it would be nice if one of y'all with access could get input from a DP on the seriousness of this. It might rate a (P5??) Bugzilla entry but I am not quite sure. At least this thread has given us a good handle on step-to-reproduce.

Given our inability to pinpoint the exact commit where the problem occurred, I think we are stumped at this point as to further debugging.

[steve]

I've submitted a report to "feedback" (I'm a bit hesitant to submit a bug report to Bugzilla myself as I can't see the problem).

[Edgar]

I can't see the problem

Try these steps:
1) generate 9 hrs of noise (if you see the problem @ 9 hrs try with fewer & fewer hrs until the problem becomes unnoticeable); leave the entire show fit-to-window
2) start playing the noise (quick -- turn down the volume as needed<grin>) anywhere near the beginning
3) click in the wavetrack somewhere near the center
4) use your keyboard shortcut to insert a label ( <CTRL + b> by default)
5) rapidly press lots of random letters on the keyboard (try to avoid any "special" keypresses)
6) stop pressing keys after 50 or 100 presses

Does 1.3.13 keep up or is there a noticeable delay between when you stop and when the final letter displays in the label? Revert to 1.3.12(10/11), try again--delay?

The length of noise needed seems to depend on your CPU speed and maybe to some extent on your OS (with Windows)--might even depend on RAM speed. Fit-to-window might not be a critical factor; where you start playing is not really critical you just need time to do the testing; where you insert the label may not be critical you just need lots of on-screen room to display the label text without scrolling.

[Gale Andrews]

Thanks for all the input. Peter was one of the first to report it to me, and I've been gathering evidence. it seems pretty much replicable on Windows on anything but a blazing fast machine. Mac shows it slightly and Linux less again. My slow Linux netbook shows it fairly clearly on a one hour track in HEAD compared to 1.3.12.

It mostly affects keyboard input but also some drags (dragging selection edges with the mouse is another operation that sometimes demonstrates it). Dragging selection edges with the keyboard can demonstrate it too. Simple to reproduce for keyboard input though - speed-type a phrase into a label and wait several seconds after you stop typing until the phrase appears. The letters appear "as you type" in 1.3.12.

The issue will only show with 30 minutes worth or more of single or multiple tracks (on a fast machine, you will need more audio to get a slowup). There is a long period of 100% CPU use whenever the holdup occurs. The consensus is that zoom level doesn't affect it.

It occurred "somewhere" between 1.3.12 release and 1.3.13 release. I suspected r10903 but I have built from HEAD the day before that change and the issue is still there, so we're looking before that date.

It's a regression on 1.3.12 and I think it must be release noted as there are complaints, so that makes it at least a P3.



Gale