Hi!

I'm trying to chase down some annoying clicks/buzzes in the IQ stream sent in the audio stream sent to my Tayloe style 48khz QSE transmit mixer. I'm quite certain there is no overrun situation or anything like that occurring. Is anyone else seeing problems like this?

I notice that the clicks start appearing as soon as the audio resampling fixup routine starts correcting the buffer fill level in "sound.c" around line 524. Until the first time this code runs, the audio is perfect, but once corrections start being made then very serious artifacts start appearing in the audio.


?I'm working on a Pi400 and some Pi4b units under the new "Bookworm" OS, but the problem is identical in the earlier os version.

Thanks in advance for any help or advice I can get on this.

M

开云体育

Hi Mario,

It reminds me of trouble I had in 2020 with Quisk on a Windows laptop, connected to a Softrock (Tayloe) radio via a Behrenger UCA202 ... it may not be the same problem, but I noticed that I/Q data out would sometimes go into what I called "buzz mode" ... it seemed that one of the ping-pong buffers in the driver got disabled, because the output would periodically (regularly every few milliseconds) alternate between normal I/Q data and silence ... made for a nasty radio signal (CW), which I would not have noticed if I hadn't been using an oscilloscope and spectrum analyzer to monitor my output.

I did a lot of poking around and experimenting in the sound_wasapi.c file to track it down ... long story short, the problem seemed to be in the driver or hardware, i.e. downstream from Quisk.? Take a look at the function quisk_reset_audio_device() in that file, which resets the driver, and see where it gets called, i.e. how the problem is detected while running.? I don't recall ever figuring out what might have triggered the problem in the driver.

Of course, this might not be your problem (different driver on different OS), but perhaps re-setting your driver might help to break out of the bad mode.

Good luck!!

-- Ben, AC2YD --

Thanks Ben, for the reply!

I've pretty well eliminated my device as the cause and focussed on the resampling method, but I will spend a little more time figuring out how Quisk processes buffers. By measurements, experimentation with modifications to the source code and a little reasoning, it appears that periodic random jumps of up to 1/2 sample value (which the present method creates) are not a good thing. ?Doing this correction to wideband IQ samples just before they are sent to the hardware the way it does, precludes doing any low pass filtering - which would mitigate the spurious transients.

Unfortunately, the nasty side effects are not easy to detect with instruments because they are transient and randomized.

I'm pretty sure the best thing to do would be to minimize the resampling during actual transmitting. Right now the algorithm runs continually. It probably could be disabled during normal transmissions if the underlying clock error is not too great. This would usually hide the correction because hams usually do low duty cycle transmissions. A bigger "dead band" in the feedback loop might also help by having it run less often.

I've been too busy to try it, but I'm going to disable the correction code completely (not the measurement part - just the few lines that interpolate or drop the samples) and try running my high resolution variable codec clock to do the correction instead. I'm fairly certain this will do the resynchronizing without side effects, but it takes a little thought to design the PLL-like software loop that will do the adjustment smoothly. Unfortunately, this would only help hardware like mine and not other use cases.

If this works, I'll report back and request an easier way to allow user supplied correction methods to be used by disabling the interpolation/drop via a configuration switch so that it doesn't require recompilation. It would also be nice to have a clean way to access the buffer fill statistics for such methods to use. I'm envisioning something easy to add to the heartbeat method in the hardware object.?

My apologies to forcing everyone to follow my missteps and thinking out loud in public about this. I was kind of hoping it would bring more suggestions like yours out of the woodwork. The two clock problem is pervasive in communications and is never easy to fix!

M

Thanks Jan

It doesn't show up here as under/overruns in the status page - but I'm pretty sure that the resampling is needed to match the microphone incoming stream to the outbound IQ stream as that channel is usually the cheapest interface. Sometimes switching microphone interface devices changes the clicking behavior here - presumably because the two cards have slightly different data rates

I find the clicks far more noticeable in NBFM mode and I too got reports of clicking from local repeater users. At first I ignored them and tried to deal with them by keeping the microphone input high as I thought it was PL tone leakage, but later when I investigated more closely I could clearly see and hear them in the transmitted signal. I think people don't notice them as much in SSB due to normal atmospheric noises.

They are often bad on FT8, but I think that depends on vagaries of Pulse Audio (which I see has been completely removed by the Raspbian developers in Bookworm!), Again, however digital users have no way to report them back to me even if they could tell they came from my signal and not those of the rest of the pack. When they're present they're quite audible and measurable in a local receiver.

On CW, the sine wave is generated locally and is usually clean and in sync - however sometimes if another mode has been in use the clicks appear for a little while during the first key down until things get settled.

I guess ideally, the incoming streams would be adjusted rather than the outbound IQ since there's certainly an LPF early in input streams. I can see why it's not been done that way, however as there are a lot of inputs of different sorts that would need to be adjusted and kept track of. It might be very messy....

I still haven't got back to work on using my codec clock synthesizer to resync the output stream as I'm in the midst of chaos from new computers and a roof replacement going on all around me, but I'll try to get back to it next week. It won't really fix quisk, but might provide a useful data point for comparison and it would solve my immediate problem.

M

Thanks Mario
I can see you have done a very thorough job.

73 Jan