On Monday 20 January 2003 08:23 pm, Josh Haberman wrote:
> > Interesting results.
> > First I recorded a rhythm track. Whoopee.
> > Then I played a lead over it. Whoopee again, right? :)
> > Then I played it back with the lead track muted. White noise with th=
> > rhythm track heard, but broken up, like a CD skipping badly.
> > Muted both tracks, the white noise stayed.
> > Muted the rhythm track, the white noise stayed, *and* the rhythm trac=
> > was clearly heard as before, like a CD skipping badly. The lead trac=
> > was barely heard.
> You could still hear the rhythm track when you muted it? Weird, very
> weird, and it definitely sounds like an audio i/o issue of some kind.
> To confirm, 1.1.0 worked fine for you, recording and playing at the sam=
Ok, here's the story as I remember it. First I tried 1.0, but no full-du=
recording for Linux. I posted to the list and was referred to 1.1. 1.1=20
didn't work with the version of wxWindows I had installed (I don't recall=
exactly why the rpm didn't work, maybe there wasn't one? Maybe I didn't =
it? Anyway...). Posted to the list and there was already serious work t=
get audacity ported to wxWindows 2.3.x. When it was done (within a coupl=
days), I pulled it from CVS. So that is the version I had. Call it 1.1+=
I belive, although I'm not certain now, that audacity at that time was=20
recording the separate tracks properly. However, I didn't get a chance t=
really beat on it, because I got this Fostex FD8 right about the same tim=
Now, however, I needed the laptop hard drive out of the FD8 for a compute=
so I'm running the FD8 as a mixer-only and audacity is now the recording=20
device. :) Since I only ever record one track at a time, this is=20
> $ cvs -z3 co -D 2002-12-01 -d audacity-2002-12-01 audacity
This version worked fine, except that when you record the second track wh=
playing back the first track it would add the first track to the second=20
track. So I ended up with a poor mix of the two tracks, rather than havi=
two separate tracks. This was unexpected behavior, actually, and because=
it I'm doubting that it "worked fine" for me ever. :) Only way would be=
me to dig even further back, I guess. Anyway, the white noise (the curre=
problem) wasn't present at all. So, except for the premature track mixin=
it was great.
> $ cvs -z3 co -D 2002-12-17 -d audacity-2002-12-17 audacity
The white noise definitely came in here.
> This will give you two separate directories: audacity-2002-12-01 (befor=
> audio i/o was rewritten) and audacity-2002-12-17 (after it was
> rewritten, and the initial kinks were worked out). If the first works
> and the second doesn't, we know the audio i/o rewrite introduced this
> problem. If neither works or both work, we'll go from there.
I guess we know the audio i/o rewrite introduced this problem. :) I can=
incrementally update the first sandbox until I reach the white noise, and=
completely pinpoint the exact day (and therefore the exact changes) that=20
caused it if you'd like, but it would definitely take some time. I'm=20
willing, though, so just let me know. :)
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> Audacity-devel mailing list
"I slipped inside the oval office,
I slipped in oh so fast,
Grabbed the president by the necktie
And wiped my funky ass, hey"