Hi Bill,
1. First, a few words about the icons. I haven't had time to trace down
the exact cause, but I established that if I start WSJT-X from the
directory into which it was installed by cmake, the proper icon is shown
on the Windows taskbar. If, however, I copy the *.exe and *.dll files
to another place and start WSJT-X from there, a generic icon is shown on
the taskbar.
2. I have not noticed the effect you mention, that Tx audio glitches are
far more prevalent near the beginning of a transmission. I'll try to be
alert for this in future.
I do still notice occasional Tx audio glitches, and they are almost
always clearly associated with heavy activity of some other Windows
program -- a browser loading a new page, 7-zip unpacking a big file, etc.
I have been inclined to blame the glitches on the Qt audio package,
mostly because I am pretty sure they did not occur when we were using
PortAudio. I believe they don't occur now in our other programs, either.
MAP65, WSJT, WSPR, and WSPR-X all use PortAudio.
Some tests and experimentation in this area is surely desirable.
3. As I've mentioned before, the decision to run the decoder as a
separate process rather than a separate thread was done first in MAP65,
as an experiment. It worked well, and it obviated some issues I had
struggled with in WSJT, which uses the separate-thread approach. The
separate-process approach was then carried over over from MAP65 to WSJT-X.
There are, of course, some potential advantages to having everything in
one process, and it's certainly reasonable to try that approach again.
As you suggest, a callback could be used to receive decoded text for
display; or the decode thread could send Qt signals to the GUI thread,
for this purpose. By all means, you should feel free to experiment with
alternative (and potentially better) ways of doing these things.
Reminder: I'll be traveling and mostly incommunicado from tomorrow
through April 8.
-- Joe, K1JT
On 4/1/2014 7:22 AM, Bill Somerville wrote:
> 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
