That's the interesting thing though. According to Jack I have no xruns with 512/2, but the pops remain (but only on Linux because using the same hardware, same USB ports, etc. on Windows has no pops).

I'm just recording my voice in 1 line of the Scarlett, so 50-100ms of latency is no problem.

You ever hear of a case where pops were coming in quite often but it wasn't related to xruns reported by Jack?

Thanks for the heads up on #jack, I didn't even know they had an IRC channel, but in theory I should be able to pull this off without Jack too since I'm not doing anything fancy (such as redirecting sound through a DAW)? Still, pops happened without Jack too.

Having pops without jack indicates that either some other software layer is choking (e.g. pulse if the audio is still routed through it) or a hardware issue. You indicate that the hardware is without issue elsewhere, so that leaves the linux ALSA driver/driver settings, pulse (if it's interfering), jack, or the recording app. I do recall some mentions of a few of the Scarlett devices having quirks in the past, though I haven't personally been all that involved in those discussions.

If jack or the recording application (connected to jack) were causing the issue then you should see an xrun reported from jack which makes me think that there's the possibility that it's being unexpectedly routed around via pulse (which can cause all sorts of shenanigans) or it's a know ALSA level driver quirk with respect to the device. The latter is unlikely as you're indicating that this is a USB device (IIRC the firewire ones were the more fussy ones). Even if you're not striving for low latency I would recommend some of the audio communities as they're likely to have stressed the same device a fair bit and may have encountered similar issues.

Thanks. Is there any chance the Windows driver has some special sauce to deal with hardware defects that alsa / pulseaudio aren't aware of? Maybe some crazy edge case defects (since it's not affecting everyone with a Scarlett).

I think I am still using pulse mainly because I installed qjackctl and pulseaudio-module-jack, but my audio devices according to pavucontrol were Jack, but it's still being routed through pulse right?

I Googled to the end of the world on this device with Linux but came up empty handed. It was just a few success stories.

Typically that approach setups up jack as the primary device user and pulse as the secondary. Your setup involves a usb audio device in addition to what I assume is some builtin audio device on your desktop/laptop. JACK's server only takes full control over a single device, so it's possible that JACK took over something other than your Scarlett leaving a different routing mechanism to shuttle data from the Scarlett to it.

As that's a mouthfull, what may be happening is:

Dev A <-> JACK <-> Pulse <-> Dev B

If that's happening then you'd want to switch the setup to:

Dev B <-> JACK <-> Pulse <-> Dev A

or

  Dev A <-> JACK <--+--> Zita-ajbridge <-> Dev B
                    |
                    +--> Pulse

Per the windows driver, I have no idea and likely neither do ALSA devs since the source is not available there. If the Scarlett driver is a standard usb-audio device, then it likely should be exceptionally robust and very similar across operating systems.

You are correct in that I also have a built-in sound card that's on the motherboard, but currently there's no microphone connected to it. I also had my headphones connected directly to the Scarlett.

When Jack was wired up with that pulse module plugin, if I talked into my the mic, pavucontrol showed the input bar jumping around. Does that mean it was operating on the correct mic? When I used OBS' jack client, it also picked up the Scarlett's mic once I wired it through qjackctl.

I know on Windows I was getting pops and cracks until I installed the Scarlett driver and specifically set the buffer to 512. Any other value would produce pops on Windows (even worse with 1024 which is weird).

If you look at qjackctl's connection window then the system:playback and system:capture ports should correspond to what jack is directly connected to. If jack is connected directly to your device, then any pops due to xruns should be recorded and displayed in qjackctl.

Yeah it was set up so that the PulseAudio JACK Sink was set to the system:playback_1 and 2, and then the PulseAudio JACK Source was set to system:capture_1 and 2.

There were pops but no xruns recorded with Jack.

Then in the OBS case, when I used the specific JACK client (as a secondary test), I wired the system:capture to whatever client came up with OBS. In hindsight, maybe that was a mistake, and I should have instead wired up the JACK sink's front-left/right instead of system capture?

It looks like HN's reply limiter has kicked in preventing further replies, so I'd recommend shifting discussion to one of the resources I've already mentioned. Based upon your most recent comment it is still not clear if jack is connected to the desired device or not. I'd recommend connecting a simple waveform viewer e.g. http://baudline.com/ to system:capture to see what's going on with respect to what jack sees as its input.

I don't know Jack, but it might be worth checking whether something like buggy automatic power management is suspending and resuming the relevant USB path during acquisition...

It is possible to disable the power management at several levels. The "powertop" utility is a convenient way to play with the top-level device/driver tunables. And the /sys/bus/usb filesystem has a power/autosuspend setting for individual devices.

Is there any tool that you can point at your pulseaudio and it would walk the whole configuration, trying you which parts are likely to cause delays? (With suggestions)

I don't know. I do not typically use pulseaudio on my systems.

I do have tools which are built to check source code for low latency compatible C/C++, but it sounds like you want something to inspect a running pulse audio daemon.

What are your views on PipeWire?

Possibly a good direction for consumer audio. Currently it lacks feedback (at the design level) for it to build into something useful for pro audio.