The title says :
My question : Are you sure it is jittering ? I mean not a latency problem. This link should help you analysing.
A/ If it is authentic sound jittering then... the problem is with the clocksource.
Depending on the configuration of your system (PREEMPT /HZ / NOHZ / NOHZ_FULL / cpu isolation...) the clock chosen as reference might not be reliable. Under a default kernel configuration, most MIDI sequencers will complain about it.
Human ears can detect jittering from 6ms shitfs.
B/ If it is latency, then the problem is at first with your sound server (pulseaudio as I can read in OP's comments) and second with your scheduler. As I knew it, pulseaudio is not a real-time sound server (I mean as jack can be, launched SCHED_RR) and your cpu (paticularly in cpu isolation conditions / irq threaded) might well be bothered with plenty of other things.
Exceptional ears (especially trained) can detect latency starting from 6ms shifts, audiophile connoisseurs are happy with 10ms latencies et most users of 48K audio 16bits sources wont detect anything below 16ms.
With the link I mentioned and of course taking care to choose a far more reliable sound source than chrome can be... (it should not be that difficult... ;-) the standard aplay can be considered as a good start), play some standard .wav (not needing any sort of cpu/gpu hungry decoder) push a step further in the analysis of your sound, is it A or B ? What are your kernel config parameters regarding the options I listed above ?...) I'll elaborate afterwards.