Re: [Audacity-quality] Mixer Board issues
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2010-11-11 01:53:26
|
| From Vaughan Johnson <va...@au...> | Wed, 10 Nov 2010 17:04:54 -0800 | Subject: [Audacity-quality] Mixer Board issues > On 11/9/2010 6:58 PM, Gale Andrews wrote: > > > > | From Bill Wharrie <bi...@go...> > > | Tue, 9 Nov 2010 14:17:48 -0500 > > | Subject: [Audacity-quality] Mixer Board issues > >> > >> On 3-Nov-10, at 2:48 PM, Gale Andrews wrote: > >> > >> <snip> > >> > >>> I've played around more in Ubuntu and rebooted several times > >>> (and initialised .cfg). I still can't reproduce your 1a) through to > >>> f), > >>> but both of these give a 100% repeatable segfault: > >>> > >>> 1) a) New Project > >>> b) Tracks > Add New > Audio Track > >>> c) Record (i.e. in stereo, which should open a new stereo track) > >>> > >>> 2) a) New Project > >>> b) Tracks > Add New > Audio Track > >>> c) View > Mixer Board > >>> d) Generate > Tone > >>> > >>> If in 1) I replace c) with Generate > Tone, there is never a crash. > >>> My 1) or 2) don't repro in Win 7. So it looks as if it could be an > >>> issue > >>> with Tracks > Add New > Audio Track, but I'm not sure what changed > >>> there since 1.3.12? Can you repro either of my 1) or 2)? > >> > >> > >> More testing on Gale's two sequences. > >> > >> 1) I cannot get this to crash on any of the three machines I have > >> access to. > >> > >> 2) This crashes on all three machines: > >> OS X 10.5.8 PPC G5 > >> OS X 10.4.11 PPC G4 Powerbook > >> OS X 10.4.11 Intel Core Two Duo. > > > > Sorry I've been silent on this. I have though been doing some playing > > around myself and 3) below crashes 100% for me on Win 7 and Ubuntu > > in two scenarios (first) with only USE_MIDI defined (as in released > > builds) and (second) with USE_MIDI and EXPERIMENTAL_MIDI_OUT > > both defined (which allows MIDI playback and adds that "Velocity" > > slider to Mixer Board): > > > > 3) a) Add an audio track (either generate or import will reproduce) > > b) Import a MIDI > > c) View > Mixer Board > > d) Click X top left to remove the MIDI > > e) Edit > Undo > > f) Edit > Redo > > > > It isn't predictable whether the crash will occur in d), e) or f), but one > > of those three will always crash for me. > > > > So we have three "similar, but not the same" crashes. Can you (Bill) > > repro 3)? You only need to test with USE_MIDI on as in the Nightly. > > > > The only common factor for me in all three is "adding a new track" > > (but not necessarily with Tracks > Add New > Audio Track). You have > > a second common factor in Mixer Board. > > I looked into this, and it's another bug introduced by Roger's commit > 10680. When I said it was okay for him to make these changes, it was > with the understanding that they would all be under > EXPERIMENTAL_MIDI_OUT and not threaten our code stability with that > turned off. > > In fixing bug 250 and looking into this, I've found he did a *lot* of it > under USE_MIDI and even more with no flag at all. I'm disappointed in > this and am going to back out his changes. More generally, I wouldn't personally regard USE_MIDI as a must for 2.0. Does this switch on the extra MIDI features that 1.2 doesn't have (MIDI "cut and paste editing" and export) or also control MIDI import? Neither the 1.2 or 1.3.13 current MIDI features are going to seriously impress MIDI users. In fact I think the MIDI "features" in 1.3.13 look very unfinished, and will always do until we at least get stable MIDI playback. > > The "spurious green lines" is obviously less important but I haven't yet > > looked again on Bugzilla. > > Are these also new since his changes? Various ways to create "green lines" have been in Linux builds for most of this year. > >> When launching Audacity after the crash [in 2)] I get the crash recovery > >> dialog. If I choose to recover the project the error log shows: > >> > >> 14:06:18: Warning: Orphan blockfile: '/var/folders/5-/5-ACi0S52RWwp+ > >> +kNLU2y++++TI/-Tmp-/audacity-Bill/project1651748620/e00/d00/e00000b1.au' > >> 14:06:18: Warning: Orphan blockfile: '/var/folders/5-/5-ACi0S52RWwp+ > >> +kNLU2y++++TI/-Tmp-/audacity-Bill/project1651748620/e00/d00/e00002d4.au' > >> 14:06:18: Warning: Orphan blockfile: '/var/folders/5-/5-ACi0S52RWwp+ > >> +kNLU2y++++TI/-Tmp-/audacity-Bill/project1651748620/e00/d00/e000031d.au' > >> 14:06:18: Warning: Orphan blockfile: '/var/folders/5-/5-ACi0S52RWwp+ > >> +kNLU2y++++TI/-Tmp-/audacity-Bill/project1651748620/e00/d00/e0000334.au' > >> 14:06:18: Warning: Orphan blockfile: '/var/folders/5-/5-ACi0S52RWwp+ > >> +kNLU2y++++TI/-Tmp-/audacity-Bill/project1651748620/e00/d00/e000077a.au' > >> 14:06:18: Warning: Orphan blockfile: '/var/folders/5-/5-ACi0S52RWwp+ > >> +kNLU2y++++TI/-Tmp-/audacity-Bill/project1651748620/e00/d00/e0000da8.au' > >> 14:06:18: Warning: Project check ignored orphan blockfile(s). They > >> will be deleted when project is saved. > >> 14:06:19: Warning: Project check found file inconsistencies inspecting > >> the loaded project data. > >> > >> And the project window opens with the empty mono audio track. > > > > Bug 20 possibly strikes again: > > http://bugzilla.audacityteam.org/show_bug.cgi?id=20 > > Much more likely a newly introduced bug. Has anyone in testing Bug 20 simulated a crash by trying to make it happen when the autosave file was in course of being written? Am I correct in thinking this could be the core problem? I agree the fact that an orphan is falsely reported could make it newly introduced, but I only did one test. Gale > > On Ubuntu if I run 2) and recover the project after the crash, I get > > an empty mono track as you do. > > > > It should I think recover the tone as it is there in the .au files in /tmp > > (unless you would argue the crash has not left time for the autosave > > file to be written properly). The autosave file only lists one .au file. > > That .au is in the /tmp folder, but it is still reported as an orphan in > > the log, along with five others not in the autosave file. > > > > On Windows, if I force quit after following 2) through, recovery is OK. > > > > I'll add this "failed recovery" scenario to Bug 20, unless Vaughan > > thinks it's unreasonable to recover the tone in this case. > > > > > >> Gale, do we need more testers/reports before raising a bug? Should we > >> ask on the forum? > > > > I don't think so, once you've tested 3). There should be three repeatable > > crashes a developer on the appropriate platform can get their teeth into. > > It just depends if we group them or not; partly this may depend what > > you find with 3). > > > > Help from the Forum testing fixes to these crashes may be good. More > > generally, Crash Recovery (Bug 20) really does need heavy testing on > > Mac with multiple scenarios because two-thirds of the problem reports > > about it were on that platform. Enlisting the Mac Forum to help with > > Bug 20 testing may be a good idea. > > > > > > > > > > > > Gale |