Audacity 1.2.x and 1.3.x are obsolete and no longer supported. If you still have those versions, please upgrade (see https://www.audacityteam.org/download/).The old forums for those versions are now closed, but you can still read the archives of the 1.2.x and 1.3.x forums.

For unknown reasons the recorded track has gaps in it. To fix I usually get away with just merely changing the *buffer-length* in preferences/devices. It doesn't really matter if it's a + or a - change. The condition most often materializes on first use but not invariably.

I've had similar results when something was hogging most of the cores on my CPU. It could be anything, but in my case I was running Folding At Home on 5 of the 6 cores. Simply pausing it solved the problem.

fredex wrote:I've had similar results when something was hogging most of the cores on my CPU. It could be anything, but in my case I was running Folding At Home on 5 of the 6 cores. Simply pausing it solved the problem.

I know what you mean I've seen similar problems while using rosegarden but is this case qJackctl is really the only other app running.

*i forgot BTW that qJackctl is running in this case also*

What seems suspect is that any tiny change in the buffer size, up or down at that, fixes it. It's almost as if some default or initial value was wrong and as soon as another one replaces it the problem vanishes, or maybe some sort of rescan takes place that didn't take place the same way initially. I'm no guru so I can only take the wildest of unfounded guesses.

Right. It's good not to leap directly into "obvious" causes and effect.

It is possible the default value is poor and any change either way will change success into failure. It's also possible, and in fact likely that the act of managing the buffer size is what's doing it. Fuzzy guess that the program isn't paying any attention to the buffer value until it's forced to.

Right. It's good not to leap directly into "obvious" causes and effect.

It is possible the default value is poor and any change either way will change success into failure. It's also possible, and in fact likely that the act of managing the buffer size is what's doing it. Fuzzy guess that the program isn't paying any attention to the buffer value until it's forced to.

Next failure, change the buffer size to the same value > OK.

Koz

Done, looks like you could be right. When I launched it was set to 50, and breaking. So I cycled to 49 and back to 50 just to create a change for the OK button to swallow and then clicked it. No more breaking.

However as I updated my thread in the Suse forum, pulling Jack out of service also does the trick. Not only that, but without jack the threshold seems to be 35 AND is evident in the form of a water-whistle like effect (for those who remember water-whistles or water-pipes) while using Jack the buffer size seems not to matter at all maybe because jack handles latency. From this point it's really waaaaaaay over my head.

fretski wrote:while using Jack the buffer size seems not to matter at all maybe because jack handles latency.

That's correct. When using Jack, the buffers are controlled by Jack. When using QJackCtl, buffers (hence "latency") are set up in "Setup > Parameters".

I won't be able to TS any further. These observations come form Suse Tumbleweed where I'm facing a new OS, a new Audacity-2.2.0 and qJackctl so it's hard to isolate the problem to one of those. If I revert to my goto rig of Suse-13.2, Audacity-2.1.2, qJackctl-0.3.11 then I can't use my new soundcard. For now I do have 2 serviceable workarounds (with or without Jack).