breaking recorded track

[fretski]

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.

breaking-130-40.mp3

(413.63 KiB) Downloaded 35 times

breaking-not-129-40.mp3

(320.06 KiB) Downloaded 40 times

These sample files have in their name the Buffer-Length and the Track-Shift.
Suse-Tumbleweed/Audacity -2.2.0, amd-8-core, 16gb ram.

[fredex]

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.

[fretski]

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.

[fretski]

there's more on the suse forum where I went fishing as well (as fitterski)

https://forums.opensuse.org/showthread. ... ost2848324

Could it be that there's something amiss in defaults, not necessarily buffer length defaults?

Also Jack is supposed to take out latency so maybe the breakup is not latency or buffer related at all?

[kozikowski]

not necessarily buffer length defaults

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

[fretski]

not necessarily buffer length defaults

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.

[steve]

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".

[fretski]

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).