I have been testing Quisk using Softrock hardware for a very considerable time now using several versions.
Over the period I have consistently had Quisk crash requiring a reboot and have been trying to detect a pattern that would readily induce the fail condition. I have used two Software radios during the testing. Both exhibiting the issue.
I find that it can, at times, take many many keystrokes before the issue appears. You my need to operate Quisk for tens of minutes with 50 to 100 keystrokes before it will crash. At other times just a few strokes after program start then Quisk would crash.
The issues SEEMS to be associated with the TOP row of buttons only. i.e. the Frequency Bands and Modes.
There would appear to be a greater susceptibility when selecting the DGT Button. If I try changing Bands back and forth and select various Modes in a random way, then it is possible to get the failure condition.
It is easy to be convinced that there is nothing wrong, BUT, it then strikes once again!
I have never had an issue while positioning the cursor within the GRAPH screen and changing frequency by that method.
If there is anything that I could try to gain more failure information then please advise.
I would very much appreciate it if you could try and find what the issue is. I hope there is a clue in the information above.
When it crashes it displays " Pythonw.exe has stopped working" or " Python.exe has stopped working"
Together with my colleague Ed (GM3SBC) we have developed the Scottie Globemaster SDR link. The Globemaster supports an extended version of the Softrock USB protocol. At this time we are very close to releasing support for "zero" latency semi-breakin CW in Quisk (we'll follow this up on a separate thread). We've been further investigating the crash issue which occasionally occurs immediately after changing into one of the digital modes (DGT*). We use Windows 7 and 10, both 64-bit. Also installed is the VB-CABLE Virtual Audio Device which is hooked up to the Digital Input and Output streams in the Sound settings config.
To assist with the debug I've added the #define DEBUG_IO 4 to the quisk.h and re-built the _quisk.pyd file. The debug log shows that during a mode change the digital input buffer size can be quite large, typically this isn't a problem, although occasionally the buffer is so large that quisk_read_sound function (in sound.c) never runs to completion, so the " finished" message never gets output. If I comment out the call to quisk_cInterpolate at line 750 then function does run to completion, even with the large data sets, although this is really just a hack for debug purposes, but it does point to a possible timing issue? Perhaps the large data sets take too long to process leading to the crash? Attached are two log files:
DGTmodeChangeCrash.txt - log showing final messages immediately prior to the crash as a result of a mode change. Note large data set "CABLE Output (VB-Audio Virtual Cable) read 336000 bytes". It took almost 100 seconds of mode change activity to induce the crash. Essentially we change between DGT mode and any other mode eg FM, AM etc. The crash occurs when selecting the DGT mode.
DGTmodeChangeOkay.txt - log showing a successful mode change to DGT-U. Data set size "CABLE Output (VB-Audio Virtual Cable) read 168000 bytes". When not changing modes the data set size is "CABLE Output (VB-Audio Virtual Cable) read 12000 bytes"
We have been able to reproduce the crash on both the Globemaster and Softrock SDR.
If there's any other diagnostic data we can provide please let us know.
Based on your research, this looks like a buffer overrun error. While Quisk is in another mode, the digital input is reading and storing data. When switching to digital, Quisk tries to read this large chunk of irrelevant data and chokes. I will work on a fix. And thanks for the work you put into this.
It looks like you are running digital modes at 96000 sps. Is that true? I always thought digital modes always ran at 48000 sps.
I have new information as our testing of Quisk Version 4.1.40 continues.
I have now been able to make it crash on several occasions.
There are TWO final display appearances.
ONE, where the Graph Display FREEZES displaying a pythonw.exe error saying that it has stopped working, and TWO, it continues to RUN but has a DERANGED Display showing a huge cyclical oscillating appearance. The Amplitude of this 'Sine' waveform is almost the entire dynamic range of the Graph Display and the Frequency is approximately 5 KHz. This waveform is being displayed throughout the entire Graph Frequency Range.
At each trough of the waveform there is Receiver Noise being displayed. This noise is audible. I can switch frequency bands and it responds without crashing.
In both conditions I have to reboot Quisk to return to normal operation.
I set up Quisk 4.1.40 with some frequency bands with the Mode set up as USB, or LSB and other frequency bands with the DGT Mode preset.
I can now make it crash when, what would appear to be when, I EXIT FROM the DGT Mode.
By selecting two Band Buttons alternately, one band having the USB Mode and the other band with the DGT Mode preset. Now switch back and forth between the two bands. Try it 50 to 100 times, at some point it will crash.
Every time it crashes it is when I select a band that has a USB (or LSB) mode FROM the previous band that has been preset in the DGT Mode.
( In our original posts it was occurring as I was SELECTING the DGT Mode and not as now, EXITING from the DGT Mode. )
I have NOT observed a crash ( to date) while SELECTING the DGT Mode with this version 4.1.40 .
BTW I am using a Samsung Laptop with W7 and a CORE i5 Intel processor for all my testing to date.
I hope all of this makes some sense ! . . . . . . . and that you can reproduce the condition at your end.
When you test Quisk 4.1.40 crashes, do you have a virtual audio cable (VAC) attached to Quisk, or is the Quisk digital device unconnected? If there is a VAC in use, is there a digital program like fldigi or wsjt-x connected too? I am trying to duplicate the simplest configuration that shows crashes.
All of the recent testing has been WITHOUT any Digital App running.
The Input and Output VAC have been selected during the testing.
Today I have had several crashes mainly towards the start of the testing, ie the first 30 minutes. ???
However it is now over an hour since I started this test session and I am having some difficulty getting it to misbehave at this time.
I shall continue the tests with the Input and Output VAC connected.
I shall in due course start testing with BOTH Input and Output VAC disconnected and report my findings.
OK and thanks. And to be sure, the crash happens when you change bands back and forth between one with SSB set and another with DGT set. And this happens on Rx and neither the Spot nor the PPT button are down.
The difference between Version 4.1.39 and Version 4.1.40 is that with the latest Version 4.1.40, the crash happens when you come FROM the Band with the DGT Mode TO the Band with the SSB Mode set.
Version 4.1.39 was the opposite. The crash happened when you come FROM the Band with the SSB Mode TO the Band with the SSB Mode set.
All these tests have been carried out on RX only. The SPOT and PTT Buttons are NOT selected at any time during the testing.
I hope you can capture this event. At times you have to be patient and apply many button selections.
One other observation which may or may not be in some way connected. I have observed at times that on changing the Bands there is a short term FREEZE of the Graph Display, then Quisk continues to operate. I would estimate that the FREEZE duration would be in the order of 500 mS.