Hi Joe, Two things on my mind related to WSJT-X.
1) Like you I am concerned about TX synthesizer glitches on Windows which seem to be down to some low level stall in the o/s or audio framework servicing the DAC. This issue is far more prevalent at the beginning of a transmission so it seems reasonable to conclude that not having full output buffers is part of the problem. So I think it might be worth investigating some synthesizer optimizations. Two strategies occur to me: a) a micro optimization where samples are buffered in a local cache until a repeat condition occurs (N full audio oscillations) and from then until input conditions change simply keep delivering sample frames by copying from the cache. This avoids the sin(theta) operation on repeating cycles at the cost of a few comparisons and a copy per sample frame when filling the cache. b) a macro optimization where a buffer (or block chain of buffers) is pre-cached from the moment the message is defined, which can be up to 2 minutes before it is needed. The pre-cache would need to be abandoned when the message changes but in the normal case we could reduce TX synthesis to trival copies from the pre-cache. Obviously before any effort is spent on this I need to do some performance tests to determine if the speed of sample frame generation is a factor in the glitches. 2) We have discussed the wsjtx/jt9 structure briefly a couple of times. I believe now is a good time to look at re-factoring this. I envisage jt9 being re-organized into a Fortran module that has an interface where a procedure pointer is passed in (a callback) and the decoder calls back with decode results repeatedly until the decode possibilities are exhausted. The callback would return numbers rather than the current formatted text and it would be down to the client of the module to interpret them. Example decode sequence: Client calls decode(&buffer, &callback, ...) Module decodes and calls callback(mode, call, dt, df, snr, msg, ...) for each decode Module returns from decode when done. Once he above is in place a simple standalone Fortran driver passing a Fortran procedure as the callback would replace the standalone jt9. The callback would simply write out the decodes in text format. Also wsjtx would link the Fortran module using a C function as the callback to receive decodes. This mechanism cries out to be wrapped as a Qt "Model" which could then be used as the model for a standard Qt "View" class like QTreeView or QTableView which would replace the current DecodedText band activity widget. The on frequency view would use a filtered wrapper (QSortFilterProxyModel) of the same model where the filter is an intersection of the (saved) RX frequency offest of the period and the decodes. This approach would eliminate the expense of managing a separate process (probably offset by the cost of running the decode procedure in a separate thread in wsjtx), eliminate the shared memory and associated locks, allow clients of the new data model to use the decodes in other ways (perhaps a UDP server to deliver them to external clients for example) and open up the decodes to other possible clients. Using the existing Qt view classes on our custom decodes model opens up all the standard Qt mechanisms for item styling and delegates to enhance the user experience of the decodes. 73 Bill G4WJS. ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
