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 https://bugzilla.audacityteam.org/describecomponents.cgi?product=Audacity
Or consider raising a bug report yourself ( https://bugzilla.audacityteam.org/enter_bug.cgi?product=Audacity ) 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 
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: http://manual.audacityteam.org/man/faq_recording_troubleshooting.html#How_can_I_record_without_small_skips_or_duplications.3F
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 
…
Audacity has it’s own user forum ( https://forum.audacityteam.org/ ) 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??