Two things you should be able to do....
#1 Run "top" to see which process is taking the most? CPU time
#2 Run "strace" on the process ID to see what it is doing.
Mike W9MDB
toggle quoted message
Show quoted text
On Monday, August 7, 2023 at 10:00:53 AM CDT, Mario Vano AE0GL <mvano@...> wrote:
Interesting to hear you are seeing it on another linux version.
I'm still working on it, but the most effective change I made was to lengthen the SSB TX delay a great deal. I'm using the maximum I can stand for voice work (around 500ms).
This continues to point to a task CPU starvation as the cause. It's much more difficult to figure out what process to blame.
Watching the CPU utilization graph during the events in question shows massive CPU use while it's happening. It's possible the Pi is hitting 100% briefly and then returning to normal as the audio ramps up.
You can get an idea if it's an audio problem or not by watching the Quisk "Status" page. It will show the TX levels coming in from the audio system, as well as those going out to the TX IQ. If, for example it's happening in Quisk, then the digital audio input will be steady, but the IQ output will ramp up. If it's somewhere else, the digital audio input will ramp up and the IQ output will track it.
Note also that older versions of WSJTX sometimes refuse to output audio at all on the first transmission. This can confuse testing a bit.
I'd like to install a later WSJTX to see if it's the culprit, but have been unable to use anything later than the one in the Raspbian repository due to competely insane dependency problems. I believe there's not currently a maintainer for the WSJTX non-PC versions (due to the death of the man who used to do it).
I'm also trying to optimize all my shared library code and QUISK hardware file as much as possible - always a good idea in any case...
I'll report back if I learn any more.
