Re: [Audacity-devel] [Audacity-quality] Possible bug in Device Toolbar
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Leland <le...@au...> - 2013-01-14 07:17:37
|
On 1/14/2013 12:14 AM, Gale Andrews wrote: > > | From Leland <le...@au...> > | Sun, 13 Jan 2013 19:03:06 -0600 > | Subject: [Audacity-devel] [Audacity-quality] Possible bug in Device Toolbar >> On 1/13/2013 3:59 PM, Leland wrote: >>> On 1/13/2013 3:24 PM, Vaughan Johnson wrote: >>>> So is the best choice for 2.0.3 to apply both patches in this thread? >>>> >>> Not so sure about that. I've gotten a bit more cautious (chicken) in my >>> old age and I'm feeling that these need more testing in the wild. For >>> the 2.0.3 release, a test as you described before should be used...any >>> sample rate greater than 200000 when using the DS host should be excluded. >>> >> This the attached... >> >> Leland > > Thanks, Leland. > > I reverted to HEAD then applied this patch. > > Summary: reasonably fast but on both my Win 7 machines I'm > getting "error opening" failures when recording second tracks > that then seem to affect other post-2.0.2 builds until I run > 2.0.2 release. > > Detail: > > I tried it on on Win 7 (netbook and laptop), Unicode Release build > of Audacity, initialised .cfg. > > Input/output sliders are not greyed under WDS and sliders interact > properly with system mixer. > > Launch and manipulation of Device Toolbar controls when WDS is > set seems slightly slower than in 2.0.2 on my (slow) netbook. If > e.g. I change from mono to stereo I see both the (1) and (2) > channel choices in the drop-down for a couple of seconds before > the combobox closes. This isn't perceptible in 2.0.2, but it isn't > really bad either. > > When I tried to record a second track (8000 Hz) against a > 44100 Hz existing track on the laptop using WDS, internal mic, > stereo, I got "Unanticipated host error" followed by "Error > opening sound device". Then I found any rate, host, input or > channel choice did the same. > > I restarted the patched build and got the same, then started a build > done at r12163 and got the same. Then I launched 2.0.2 release which > did not have the "error opening" issue. Then I started the patched > build and it no longer had the issue. > > I initialised prefs again and using the patched build I tried recording > a second track at the same settings that failed. It was fine for > many tries but finally the errors appeared again recording a second > track. > > Repeating the procedure on the netbook with your patched build > I see the same issue; after a while doing repeated recordings, > recording a second track will error, and continues to error until I > launch 2.0.2 release. > > I have not (yet) got your "dsound_isformatsupported.patch" build > (without the extra "usecachedrates.patch") to start the second track > errors going. Nor does my r12163 build seem to start the errors > going. > > Do you see anything in the current "dsound_rate_quickfix.patch" > that could be suspect? Or could there be some interaction between > it and the resample changes in r12170? > I can't get any failures to occur. But to clarify, you have a clean HEAD copy with just the dsound_rate_quickfix.patch applied? Nothing else right? I ask because I can't imagine how the patch could cause errors as you describe since it just limits the highest playback and capture rates to 200000 or less. And I can't explain why it would be noticeably slower since it only adds a couple of tests. Puzzling... :-( Leland |