audio quality degrades randomly? about loop-baby HOT 10 OPEN

I think it's at least sometimes the signal being too hot. so turning down the volume of the input signal should often help this.

from loop-baby.

Okay, added input/output gain control in #34, which I'm pretty sure was always the cause of the problem anyway.

from loop-baby.

clues:

• it's not SL, because the quality is shit in audacity too
• restarting jack fixes the issue, but so does just waiting for a while
• it's not my speakers, because if I just play directly through them it's fine
• it's not the audio output, because if I play audio recorded prior to the beginning of the fuzziness it sounds just fine

so these clues lead me to think that it is somehow related to jack, and specifically the audio in part.

from loop-baby.

I think the key was changing the jack period to '-n 3' because apparently usb interfaces tend to prefer that.

seemed to work...maybe?

from loop-baby.

Okay, so it's back to doing it. I had removed the '-s' and it gave me xruns even with just 4 tracks. So then I added back '-s' and eventually the crackling returned.

My current best guess: the '-s' softmode option prevents the xruns being reported, which preserves the looper working. but then once the xruns happen, the audio degrades. no idea if this is right but that's my best guess.

from loop-baby.

from this link here I think I'm probably correct: xruns cause crackling.

so I should increase the -p to 1024, resulting in more latency.
or I can try to disable other processes, like networking, or maybe try overclocking?

from loop-baby.

need to check cpu/ram usage (with top -u mpd maybe?) to see if this is related to the issue. if so, I can try overclocking, and turning off unneeded processes.

https://www.runeaudio.com/forum/tweaking-the-audio-performance-rpi3-t4301-30.html

from loop-baby.

nothing suspicious in top.

while working:

and again, during the xruns:

from loop-baby.

when playing with jess, it always happened to us (the fuzziness) when we got to the fourth track (i.e., three saved, playing on the fourth). so possibly it's like jack not processing quickly enough once SL is using more RAM. so I'm gonna guess it's a ram issue?

if so, does setting a shorter max_loop_length param decrease memory demands?

from loop-baby.

okay, so actually I think it's a CPU issue. as you record more loops in SL, the CPU usage grows (but MEM does not):

before:

after (with four loops):

then, clearing the loops decreases CPU.

I did two fixes, which helped me get to four loops without immediate crackling:

• changed SL's max loop length from 40 secs to 20 secs
• booting the pi without a desktop GUI (though I might actually need this to run jack since dbus is built in, apparently)

from loop-baby.