[pulse bridge] Stuttered Audio Playback after xruns

It might not be any help since it's a discord-log... but it reports some underflow issue:

[011:561] [10873] (audio_device_pulse_linux.cc:1762): Playout underflow

Maybe this helps to get some direction on it.. idk.
(I know that neither the filename nor the line number is really helpful since it's related to closed source software^^)

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.

might have been easier to have you use:
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh >adevices-jack
and
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh >adevices-pulse

I'm using such a large buffer because I encounter less problems using ardour that way. Also for smaller buffer sizes, my voice was sounding "weird" (that's what I was told by my friends in voice chat), so I kept the large buffer size.

48kHz vs. 44.1kHz sounds a bit strange, because I was always using 44.1kHz earlier (including on my old ubuntu installation, where everything worked fine). But for the sake of testing, I tried 48kHz too - and I WASN'T ABLE to REPRODUCE the behavior.

Also I tried 44.1kHz with a smaller buffer (512) and NEITHER can I REPRODUCE it with these settings.

About the logs... I've added my jackdbus.log as attachment. I'll add the rest via seperate comments (cannot select multi files for attachment).

Greetings

/proc/asound/PCH/pcm0p/sub0/hw_params

/proc/asound/PCH/codec#0

Well, I'm using a USB interface (Focusrite), but :

/proc/asound/PCH$ ls
codec#0 id pcm0c pcm0p pcm2c

@Len Ovens (len-ovenwerks): here's the adevices-jack output file

Sorry for the delay, Anyway, the device is able to use 44k1 without problems and because VLC works fine we can probably rule out jack, and pulse too. Studio-controls is just a script that runs jack and adds bridges to it using software that is not a part of studio-controls so it is not studio-controls specific. Really, that leaves discord either not liking 44k1 or not being able to deal with large buffer sizes. It would be interesting to know what discord asks for when it opens the audio device. You can check this by stopping jack in studio-controls, make sure vlc is not running, run discord and while discord is running run:
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh >adevices-pulse
Attach adevices-pulse here or look at it yourself. The lines to look at are:
used by: pulse
rate: 44100 (44100/1) - The 44100/1 means it really is 44100 as measured by the computer
period_size: 4096 - what we call buffer size, the amount of memory pulse can deal with per period
buffer_size: 8192 - buffer size X nperiods, the application deals with one half while the device deals with the other and then they switch when the device says so (at least in jack) pulse does other things sometimes.

Thx for your reply! :)

The log looks like 44.1kHz and a huge buffer oO - I attached it anyway.

Btw discord quit support for my issue because I'm using an audio interface .. lol.