breaking recorded track

Help for Audacity 2.x.x on GNU/Linux.
Forum rules
ImageThis forum is for Audacity 2.x.x on GNU/Linux.
Please state:
  • which version of Linux you are using,
  • the exact three-section version number of Audacity from Help menu > About Audacity,
  • whether you installed your distribution's release, PPA version, or compiled Audacity from source code.

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.
Post Reply
fretski
Posts: 31
Joined: Wed Jan 06, 2016 1:05 am
Operating System: GNU/Linux other

breaking recorded track

Post by fretski » Mon Dec 04, 2017 6:55 pm

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 16 times
breaking-not-129-40.mp3
(320.06 KiB) Downloaded 17 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
Posts: 9
Joined: Wed Oct 04, 2017 12:27 am
Operating System: Linux Fedora/RHEL

Re: breaking recorded track

Post by fredex » Mon Dec 04, 2017 7:46 pm

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
Posts: 31
Joined: Wed Jan 06, 2016 1:05 am
Operating System: GNU/Linux other

Re: breaking recorded track

Post by fretski » Tue Dec 05, 2017 2:48 am

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.

fretski
Posts: 31
Joined: Wed Jan 06, 2016 1:05 am
Operating System: GNU/Linux other

Re: breaking recorded track

Post by fretski » Sat Dec 16, 2017 9:55 pm

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
Forum Staff
Posts: 40454
Joined: Thu Aug 02, 2007 5:57 pm
Operating System: OS X 10.9 Mavericks
Location: Los Angeles

Re: breaking recorded track

Post by kozikowski » Sun Dec 17, 2017 1:31 am

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
Posts: 31
Joined: Wed Jan 06, 2016 1:05 am
Operating System: GNU/Linux other

Re: breaking recorded track

Post by fretski » Sun Dec 17, 2017 5:39 pm

kozikowski wrote:
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
Site Admin
Posts: 47297
Joined: Sat Dec 01, 2007 11:43 am
Operating System: Linux *buntu
Contact:

Re: breaking recorded track

Post by steve » Sun Dec 17, 2017 5:45 pm

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".
9/10 questions are answered in the FREQUENTLY ASKED QUESTIONS (FAQ)

fretski
Posts: 31
Joined: Wed Jan 06, 2016 1:05 am
Operating System: GNU/Linux other

[workaround found] Re: breaking recorded track

Post by fretski » Sun Dec 17, 2017 6:42 pm

steve wrote:
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).

Post Reply