NEWS: I captured the “jittery font” issue on 2.1.2! Please see this 14 second video. Sorry for the focus in the middle. That last 5 seconds CLEARLY show the jittery/fidgety timer fonts on the Timer Record dialog box. https://youtu.be/WFxaJWx47K4
Why do I think that has something to do with this? Well, back in the old days (Windows 95) I worked on a C++ project that exhibited this behavior. I was not doing the graphical UI, it was someone else. I was essentially his tester since the GUI drove my embedded back end. He had all kinds of mutex, interlock and interrupt capture issues. Whenever we saw this kind of thing, it pointed to some sort of interrupt mutex or semaphore. I’m just saying… I don’t see this on 2.1.1 or 2.1.0 at all. It is occasional on 2.1.3RC2.
Peter: congrats on getting a little re-create activity. Maybe you can find a hard path to the issue. I also saw the “works for 10 seconds but stops” version of this with 2.1.2, but I haven’t been able to recreate it! As for doing a “save project” before or after: on my setup, it makes no difference.
Do wxray or waxcylinder see much higher CPU use in Timer Recording in 2.1.2 than in 2.1.1? I do, but it isn’t clear what commit caused that or whether the high CPU is actually a trigger for the bug. I get the high CPU use whether the bug triggers or not.
I do get the bug 100% reliably in debug builds but it needs to happen on a developer’s machine to get to grips with it.
YES! I see average CPU usage for Audacity of 35% during timer record (but not regular record) on 2.1.2, and only 9% on pre-2.1.2. That’s an important clue.
Yes, but differently and not as severely. I see a very slight flicker in “selection start” when the moving graph updates a full page. It is pretty rare and you can barely see it. The numbers in the TimeText timer dialog look like they’ve had way too much coffee and are just jumping all around. Much stronger.
For me it’s not the counters but flicker thay seem pretty stable - for me it’s the slider buttons in the Mixer Toolbar that have a serious case of the shakes and that’s only after seven seconds (and that’s very consiatent).
not quite so consistently recreated - on the same W10 laptop the refused to honour the Stop consistently when I was testeing yesterday morning behabed differently yesrdat evening when I idly tried again as I was getting ready for bed.
a) with the latest alpha it consistently honoured the Stop after the 10 seconds or so
b) with RC2 it remained not honouring the stop.
BTW more careful testing seems to indicate that the cut-off point for the behaviour change is not ten seconds or so - rather it seems to happen after the 7 second mark (at that’s the time when the jitters on the Mixer Toolba sliders occurs). So it looks to me as though on W10 something strange happens with TR at 7 seconds
And now today I can’t get the TR Stop to fail at all - consistently Stops fine on RC2 and on audacity-win-r0efe931-2.1.3-alpha-03-mar-17 (and fine on 2.1.2)
What have I done in the meantime: un-installed TrueKey that inveigled its way in unwanted throgh the backdoor as part of an Adobe Flash upgrade. And that required a reboot.
No other changes - I’m totally puzzled …