I got serious about pops, crackles, ticks, and things over on the test team list. I'll grab that and add it below this. Warning - it is a LOT of material to absorb. Inevitably math intrudes; but, it's simple "you can't graduate high school if you cannot do this arithmetic" stuff.

{^_^}
===8<---
You are using small buffers to reduce latency, right? That factors into the following analysis.

Data is coming in generally at very high sample rates, call this frequency X samples per second. In the reception process it gets "down converted" and decimated, usually by a factor of 2^N. Eventually you get down to something like 100 ksps to as low as maybe 8 ksps. Regardless it is a rate determined by the front end sample rate and its frequency error. Call this Y in (1 + px). px is usually 0 to */- 0.0003.

The sound card works at sample rate Y, usually 48 ksps plus or minus a bit, py as with px above. In order to mate the date stream with the output data stream requirements you need a resampler.

To put some numbers on this I'll be cheeky and presume a typical high quality RTL dongle working at its optimum sample rate, 2.4 msps and a 48 ksps sound card as found on computer motherboards. The dongle is 1 ppm out. The motherboard is a bad one at 50 ppm out. The SSB signal is decimated and otherwise tweaked by powers of 2 down to 9.375 kHz, a division ratio of 256. I need to resample that up to 48 ksps. The resample ratio is 5.12. And it's all fixed ratios. So we deliver samples at 48000 * ( 1 + px ) to a device that wants them at 48000 * ( 1 + py ). Pushing the error around we essentially have an error of ( 1 + px )/( 1 + py ). In approximate terms this simplifies to ( 1 + px - py ) if we ignore px * py or py^2 terms. So we can approximate and say we are delivering 48 ksps plus an error to a 48 psps device. Suppose the audio buffers are 1500 samples. Every time the output demands audio the system has prepared 1500 * ( 1 + px - py ). This is cumulative. After awhile a buffer can come up short or long by one sample. What do we do about that sample. What do we do about the excess buffers when we've filled our limit of buffers? We could grow the buffer pool - a memory leak in appearance. So that solution is out. Besides if we come up short we don't have a buffer ready for the output when the output needs it. We get a hitch in the audio either way.

I have seen an application work by fidding the resampler ratio by tiny amounts to account for the differences in rates. This is a fairly finicky adjustment. But it's the only artifact free trick I have seen yet.

(Yes, Loren has used that in SoundMan Server, that cute little 1024x1024 ASIO based mixer, delay, equalize, low latency audio tool he sells. It was in his work to allow multiple digital sources and sinks that are not precisely in lock step with each other. It is hard enough to make stable at the 64 sample buffer size he uses that this was put on a back burner to simmer. I think that fire went out.)

{^_^}
===8<---
I suspect you will find that all sound cards will tick, click, pop, whatever it does. There MIGHT be some sound processing system that includes a resampler process that matches incoming data rate to the sound card itself. That effectively means EVERY tool that connects to the sound card must either adapt its rate to the sound card (file playback) or get its audio resampled with an adaptive rate resampler (SDR processes). All you can do is negotiate how often.

There are two models for AV data streams. One is pull, the destination sound card (output) drives the timing by asking for buffer loads as it needs them. The other is "push" where the sound card (input) pushes audio to its consumer as it gets full buffers and it's the rest of the software's job to use it in time for the next buffer load.

The collision happens when you have a push source coupled to a pull destination. If the two are on the same card working with the same clock there is no problem. That is how Loren's SoundMan Server works. Because everything is off one ASIO one sound card or set of sound cards that are all precisely synchronized with each other the inherent push is matched precisely by a corresponding pull.

The differences you see are likely due to relative frequency differences vs buffer sizes. Suppose you are a net 50 ppm different in frequencies at 48 ksps, the most common rate for PC audio in videos and the like. So over 1 second you get either 48000 * ( 1.0005) or 48000 / ( 1.0005 ) samples, The net error is 48000 * 0.0005 or 24 samples. If you are running on 64 sample buffers, the smallest ASIO allows, that means you tick about once every 2.7 seconds. For a buffer size of 1500 (fairly common) it ticks about once a minute. For reference 64 samples is about 1.333 ms and 1500 samples is about 31 ms. Very often multiple buffers are used to give very long effective buffering. For 50 ppm error divide the total use buffer time by 24 and you get you time between ticks.

If that IS your problem the solution MAY be very long latency in your audio due to a very large pool of buffers. Or it may involve somebody actually making variable timing on the resampling work. (I an some time away from experimenting with this aspect of SDRs. I plan to doctor the use of the CuteSDR resampler to include an estimator for the sample rate error, which is very ugly to do with the small buffers I want to use. I just ripped up a lot of what I had done so it could be more flexible. I have to glue it all back together to make it work. Meanwhile we're running ethernet wire all over the place.... I've grown sick of the vagaries and lack of privacy given by wireless networking.)

{^_^} ===8<---