Hello Bill, Joe, et al, Bill, I think your suggestion for a callback function would be very good. It would simplify things. Putting the decoder on a lib is also very good. This brings back an idea I have been thinking about recently: The possibility of detaching the DSP and audio engine from the GUI in WSJT-X for a new application. The engine would be accessible via TCP/IP in order to enable remote operations. This could also enable the development of clients for portable phones, tablets, etc.
On the audio issue, a while back I recall Joe mentioning that the main reason shared memory was used in wsjt-x was because the amount of data needed to be passed around for the slower (longer) modes. Since we no longer have the longer modes, would it make sense to revisit the idea of saving the audio in a wav file and passing the path to the file for the decoder? This could help running wsjt-x on devices with small memory footprints (RAspberry Pi comes to mind). The wav file concept could also be used for TX. Instead of generating the tones in real-time, a wav file could we written and at TX time, it could be played. Would there be drawbacks on this approach? 73, -- Edson PY2SDR On Tue, Apr 1, 2014 at 10:49 AM, Bill Somerville <[email protected]>wrote: > 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 >
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
