On 01/04/2014 14:34, Joe Taylor wrote: > Hi Bill, Hi Joe, > > 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. Ah, that's a sequence I hadn't tried. I should be able to find out what is going on there, surprising since the Icon is embedded in the exe file. > > 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. The Qt audio framework on Windows is a fairly thin layer on top of the MS WaveAudio framework but of course the devil is in the detail, perhaps some profiling of the Qt audio code is a good place to start looking.
> > Some tests and experimentation in this area is surely desirable. I will carry on investigating. > > 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. I think that Qt specific code (sending signals for example) is probably best kept out of the decoder, a simple callback mechanism keeps the code highly portable and would remove all Qt dependencies from the decoder library, the others being related to the shared memory. Although a small point, I think that having a decoder callback with numeric arguments is important. Aggregating the decoded data as a string prematurely denies us a lot of flexibility in processing and displaying decodes. > > Reminder: I'll be traveling and mostly incommunicado from tomorrow > through April 8. > > -- Joe, K1JT Have a good trip 73 Bill G4WJS. > > 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 ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
