audio quality degrades randomly?

[mobeets]

things to check:

• the cheap usb interface?
• clipping because signal too hot?
• my shitty speaker?
• something to do with alsamixer?

edit: sometimes it was the signal being too hot. but most of the time it's because of silent xruns.

[mobeets]

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.

[mobeets]

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

[mobeets]

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.

[mobeets]

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

seemed to work...maybe?

[mobeets]

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.

[mobeets]

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?

[mobeets]

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

[mobeets]

nothing suspicious in top.

while working:

and again, during the xruns:

[mobeets]

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?

[mobeets]

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)

[mobeets]

here's the situation: audio crackling happens when you call jackd with -s. the crackling happens because there are xruns, and jack is ignoring them. if you instead try calling jackd without the -s, you will be able to see all the xruns, but then it will block audio entirely and the looper will not work at all.

so the reality is, it's best to run jackd with -s and deal with the resulting (occasional) audio crackling.

i've tried to run jack with a large buffer size, so -p 1024 and -n 3, and --no-realtime. but still, this happens occasionally.