Audacity recording breaking up

I don’t know if this is an Audacity (2.2.0) problem or not. Recordings made via Mic or Line-In are often full of tiny ‘silence’ gaps. The fix is to change the buffer length in Preferences/Devices. Strangely it makes no difference to what, a single millisecond edit in either direction may do.

Using Audacity 2.2.0-14.1 (TW 20171206) and a buffer length of 100ms (unchanged default) I’m not seeing that problem. At least not for the line input, I don’t use mic input.

Perhaps check the Audacity bugzilla

Or consider raising a bug report yourself ( ) if it’s a bug you’re able to reliably reproduce.

Rather intrigued by this, so investigated a little further.

Doh! … If in doubt, read the fine manual, or consult the FAQ :slight_smile:

This is not a bug per se. But rather means that Audacity cannot write the audio to disk fast enough to keep up with what it’s recording. So it would be hardware dependent to a degree, hence you seeing the problem, I don’t.

Take a look here:

Thanks. As I noted in the OP merely EITHER increasing OR decreasing the buffer length by 1 fixes the problem (I was using 110 btw as that gave me no latency problems without Jack). I now use Jack almost all the time. But you’re right, the checklist in the manual is also useful. With my onboard card I was constrained to recording in stereo but with my new card I can record mono and that also takes the problem out right off the bat, which is a better way to do things.

spoke too soon, the problem is back unaffected

Full length of file shown in Audacity
View-clipping OFF
Software playthrough OFF
Recording Mono
Buffer 110
Track shift -30
Tons of spavce on drive
renice qJackctl -10
renice jackd -10
renice Audacity -10

I’d first try changing the buffer length again, but by larger amounts, try 200ms, 300ms, and although it may seem counter-intuitive perhaps reduce also, 50ms, or even 0.

Noted that you’ve changed the “nice” settings. Was it possible though at the time of recording you had some other processor or I/O intensive activity running, disk indexing for example?

I know this is not comparing like for like, but I’ve just been playing around on an AMD 64x2 5600+ system with 4G RAM and a rotational drive. Using all default settings and only changing the buffer length I don’t run into skipping until I drop the buffer length down to around 40-50ms, and that’s recording stereo 44100Hz 32-bit…

Never had any problems with this myself so not had reason to look at it before, I’m as in the dark as you are :wink:

Audacity has it’s own user forum ( ) If you’re unable to resolve the problem I’d ask there, those folk are likely far more knowledgeable.

Nicing reprioritizes but in this case has no effect. I tried 40 & 300 and default 100 all to no avail. I’m beginning to think it’s a defaults issue but not necessarily buffer defaults.

  • launch with 300… breaks up

  • edit to 110… no breaks

  • launch with 100… breaks up

  • change to 101… no breakup

  • launch with 101… breaks up

  • edit to 99… no breakup

  • launch with 60… breaks up

  • edit to 20… no breaks

  • launch with 20… breaks up

  • edit to 10… no breaks

  • edit to 0… no breaks

  • launch with 0 breaks up

  • edit to 1… no breaks

Seems that I get breakup on first attempt to record regardless of buffer pref in effect until I edit buffer length to any value.

I tried with qJackctl out of the loop and the symptom is gone. There are other symptoms with only Audacity running (sounds like a waterpipe) but that comes into play around a buffer length of 35 ms.

So, what do I have here, a Jack issue?

I never had this problem before but I noticed it started after I loaded Windows 7 and started using the latest beta Audacity 1.3 version. I also use Adobe Audition and have never had this problem either. You think there is a bug in the program??