Let me jump in and add a bit more information.

I am not an RF guy - I stopped playing with radios [and TV] in the days when they used vacuum tubes (yes, really.)

Many laptops share radio and antenna resources between WiFi and bluetooth.

Bluetooth lives on the 2.4ghz band.  Wifi presently uses both that band and also a 5ghz band.  Different antennas might be used for each.

I encountered Wi-Fi/Bluetooth contention issues a couple of years back....

My home wifi has (or rather had) distinct SSIDs for Wifi on the 2.4 and 5ghz bands.  It was a rough attempt at manual load and distance balancing.

(Our house is in a relatively quiet area, RF wise, so there's not really any seriously competing wi-fi - or for that matter cell signal, broadcast TV, or FM radio.)

I began to notice that when I had one of my laptops on the 5ghz WiFi and was listening to music via some bluetooth speakers that my remote terminal keystrokes sometimes had that sluggish feel that is familiar when doing remote terminal command-line stuff over long paths with a lot of latency/jitter.  And at the same time the music via Bluetooth often broke up or stuttered.  There was a clear correlation between the two problems.

I had heard from some Linux kernel developers that deep down in the Linux kernel the simultaneous use of Wifi on a 5ghz channel and bluetooth on 2.4 causes a lot of thrashing and flogging of the the radio system.  I don't know, but I suspect that as a result there are queues of outbound traffic waiting for the radio or antennas to become operational on the channel they need.  I have no idea what happens to inbound frames when the radio system is tuned elsewhere - I never measured whether the frames are lost or delayed.

I suspect similar issues are present in *BSD, MacOS, and Windows kernels.

So I did some simple empirical testing to compare life with the laptop coerced to use an SSID present only on the 2.4ghz band.  The problems went away.

I went back to the laptop, but coerced onto the 5ghz band for WiFi and, voila, there was trouble.

I've done this with a MacBook Pro (circa 2015 model) using various versions of MacOS and with my rather newer Linux laptops (mostly Dell XPS units with Fedora.)  Same sorts of behavior.

These were all i5 based units with 2 or 4 cores - plenty of CPU power to simultaneously handle an SSH remote console client and a music player.

I did not test with mobile phone or tablet platforms.

I do not know if the single radio issue is the result of cost savings or some radio-engineering or antenna issue.  I do suspect that these things could become more troublesome as WiFi 6 and/or 5G start to use some of the higher frequency allocations around 5.9 and 6ghz.)

(A few weeks ago we switched our home WiFi to a WiFi 6 [Netgear Orbi-6] mesh system that does not appear to allow separate SSIDs for the 2.4 and 5ghz bands, so I can not repeat these tests without constructing a test network with the now unused access points.  BTW, I did encounter the hell that is known as "reconfiguring dozens upon dozens of different kinds of IoT devices to use a different SSID".)

Looking somewhat off topic - it is my sense that we will be seeing a lot more latency/jitter (and packet resequencing) issues in the future as radio systems become more agile and as we begin to use shorter (millimeter) wavelength frequencies with reduced ability to penetrate walls that, in turn, cause more frequent access-point transitions (with possibly distinctly different backhaul characteristics).  I've observed that these things can cause trouble for some TCP stacks and some non-TCP based VoIP and streaming applications.

        --karl--

Hi all.

So I may have fixed this for my end, and hopefully others may be able to use the same fix.

After a tip from Karl Auerbach and this link:

    https://developer.apple.com/forums/thread/97805

... I was able to fix the problem by disabling Bluetooth.