Comment 3 for bug 1909030

Some questions... and log file requests.
I see you are using 4096 samples of buffer, Is that because you are using HDMI? or some other reason? Are you using a discord client or a browser instance? Does htop show one core running at 100%?

Could you attach:
~/.log/jack/jackdbus.log
If The device you are using for output is internal, the file:
/proc/asound/PCH/codec#0
or if it is USB:
/proc/asound/PCH/stream0
Also of interest:
/proc/asound/PCH/pcm0p/sub0/hw_params

In the above three cases the device would be PCH,0,0, If your's is different (eg, Device,1,0) then change the PCH to Device and the pcm0p to pcm1p. All of these should be copied while jack is running and also with jack not running but with discord still working through pulse.

My first guess is that discord runs at 48000 and not 44100 or that your audio device only works at 48000. (JACK will use the device at whatever it is able to get but still tell the world it is running at what was asked for) So in this case you asked for 44100 but the device is 48000 only so JACK runs at 48000 but pulse thinks it is running at 44100. Something like VLC, may handle that fine because it is just sending the next 4096 samples when they are asked for but because discord is live it will get asked for the next 4096 samples before it has them to give because it is working at a slower sample rate.

In any of these cases, Studio-controls is not to blame, but rather JACK or the pulse-jack bridge (pulse module) Studio-controls does not handle audio itself at all, it is a script for running JACK and other utilities and creating some connections along the way.