Audacity 2.x - More Resource Intensive?

What you have posted is the Audacity project file (the xxx.aup file). This contains no audio. It only contains instructions used by Audacity to assemble the audio file. You need to produce a File > Export of the first few seconds if you want us to be able to see and hear this file as audio.

Oh darn. (blush)

And I threw out the bathwater right after I uploaded it. I’ll get another one by tomorrow I’m sure.

I said “fenceposting” but should have said “picketfencing”, apparently I forgot to caffeinate this morning too.

What bug was that - something to do with 24-bit > 16-bit dither?

On the dither question ( ), 2.x and later 1.3.x wrongly add dither noise (if dither is enabled) when exporting from 16-bit projects to 16-bit WAV, though the general consensus is that using 32-bit quality is better anyway (with dither enabled).

Yes a RAM disk may work for you. I tested this one (free up to 4 GB) recording 32-bit 192 000 Hz on Win 7 x64 without dropouts ( ) .


So you mean you enabled “Audio Cache” - and this was the first time you got drop-outs using it?

Did I understand that the Behringer connects to the laptop with some USB to card adaptor? Is it a USB 2.0 adaptor? Are there other USB streams going on at the same time as recording? One trouble with a laptop is that interrupts are often shared.

Are you on Vista Service Pack 1? It might help if not.


Hi Gale.
"So you mean you enabled “Audio Cache” - and this was the first time you got drop-outs using it? "
Yes, the cache was on. I’m not sure if this was the first time I got drop-outs with it on, but the first time I was SURE it was on when they happened.

And, FWIW, last night I recorded a whole album, with NO CHANGES from the setup that had intereference in the afternoon, and I intentionally ran MISE, Outlook, live tv on the computer…hammered on it, and got no interference at all.

“Did I understand that the Behringer connects to the laptop with some USB to card adaptor?”
No no no no. I have two choices of audio input. A Creative FX card, which plugs into an “ExpressCard” slot.
OR the new Behringer, which simply plugs into the USB bus. Two totally unrelated audio adapters, one uses the USB bus, the other uses a dedicated card slot. So there’s no question that the noise is somehow related to the USB bus, because the noise is the same even when I am NOT using a USB adaptor at all, not using the USB bus at all. It is a USB 1.x bus as far as I know. NO other USB streams going on at the same time as recording, and since the trouble occurs on the card device as well as the USB–that should eliminate any question of this being a USB issue.

“Are you on Vista Service Pack 1?” Yup.

Started to record again this morning, two tracks with zero problems…there’s never a gremlin around when you need one, is there?

SUCCESS! I’ve got the gremlin in a bottle, here, let me upload it as an attachment for you. OK, now ALL I had running was one MSIE browser window and Audacity 2.x. No live tv, no email client, none of the other stuff that I had running without problems whilehammering away last night. Just one MSIE page and I happened to be scrolling down that page, something which did NOT create any problems in the last hour or more. And now, distortion. So I’ve attached it as an MP3 file, the distortion starts about 5 seconds into the file. (The forum software complains about file size if I use WAV.)

Gale, I’d swear Audacity 2.x has a problem with epileptic fits. Over the last few days I’ve kept trying to figure out how, or hwne, or why, it does the picket-fencing noises and can’t find a single common factor. Which I know makes it damned hard to troubleshoot.

I’ve had the computer running six tasks at once (email, live TV from a USB dongle, multiple internet sessions, etc.) and 2.x works like a champ, no problems at all. And then, next session or next recording? With NOTHING else running at all, it still f-f-ff-umbles the audio.

I’ve even tried changing the hard disk write scheme, i.e. en/disabling write buffering in the “performance-vs-reliability” settings. No difference either way. Audio buffer on or off, no difference. Higher priority, some difference but no salvation.

My workaround is to use 1.2.6 for recording, and then reopen the file in 2.x for edits. Which of course always complains about orphan bits.

I can only guess that 2.x is handling writes in a very different manner, and that when it sees or smells SOMEthing, something normal that has nothing to do with resources being used by other apps, it goes off into some kind of loops and has the epileptic fits. I can’t see this being a resource shortage in any conventional way–not when the problem occurs when nothing else is running, and doesn’t occur when gobs of “everything” are being run.

I’ll keep looking, but eyeballing resources and processes doesn’t show anything that seems causitive, much less coincidental. It just seems like the process being used to write to the disk is flawed. (And I’m guessing that’s a totally different section of code from 1.2.6.)

Just a thought, are both Audacity 1.2.6 and Audacity 2.0 use the same temporary folder or do they save temporary data in different locations? (see the Directories tab in Preferences)

1 is set to the default, i.e. a temp folder in the user directory on the c: drive, which has lots of other things on it but 50GB free as well.

2 is set to the wide open spaces on the d: partition, which is on the same physical drive (A WD Scorpio Blue SATA3 on a SATA1 internal bus) butD: is the library, and has some 250GB of free space on it right now.

There shouldn’t be any thrashing, the Scorpio’s have plenty of buffer built in. Unless WD has a problem with these drives that I haven’t heard about.

Are either of those partitions automatically defragmented, compressed, search indexed by Windows, monitored for changes by a media player or backup service, or anything like that? It may be worth trying setting Audacity 2.0 to use the same temp folder as Audacity 1.2.6 (as an experiment).

No, I have searches disabled. I defragment manually and infrequently, since NTFS does some of that by itself. And this drive was installed by up-cloning a smaller one a few weeks ago, so it is pretty much defragmented to start with. No encrypttion, no compression, no monitoring by any sync software of any kind.

Easy enough to point 2 back to the older smaller partition that 1 is using…I’ll do that and let you know as soon as that fails. (Hey, I’m an OPTIMIST, I’m looking forward to the failure as proving one more thing isn’t the problem.)