On 01/04/2014 15:39, Edson W. R. Pereira wrote:
Hello Bill, Joe, et al,
Hi Edson,
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.
Yes, exactly the sort of things I have in mind with many of my changes
so far and yet to be proposed. At the moment there is far too much
coupling between the GUI, the control logic and, the DSP engine(s). If
we could get to a modular decoder along with the largely already
implemented decoupled audio i/p and o/p, my next step would be to
decouple the control logic from the GUI code. Qt has a nice state
machine framework that integrates well with Qt signals and properties,
that would be a very good candidate technology for a modular controller.
After all, the use cases of operating a WSJT? station are easily defined
and implemented as a formal state chart.
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?
AFAIK the shared memory is simply a vehicle for passing a large audio
buffer, partial transforms and, some parameters to the decoder running
in a separate process. Chunks of the buffer are passed to a DSP engine
to get the dynamic signal trace and waterfall but the whole period
memory footprint of that buffer is needed somewhere as the decoder needs
to chew on the whole thing (I may be wrong here and incremental decoding
may be possible, Joe?).
Saving the RX audio to a WAV file has its own stand alone merits so I
don't think we want to lose that facility which is relatively cheap
since we choose when to do it.
Currently the i/p audio buffer (whole period at 16-bit 12kHz mono rate)
is in the wsjtx memory footprint and shared with the jt9 process, having
the decoder as a subroutine would simply mean passing it a pointer to
the same buffer. No change in footprint but much simplification with
only one process address space and no locking requirements.
As for TX audio synthesis, I'm not sure a file cache would have any
benefits over a memory buffer. Either way; until the root cause of TX
audio glitches is determined, simple synthesis on demand in near real
time is probably best.
73,
-- Edson PY2SDR
73
Bill
G4WJS.
On Tue, Apr 1, 2014 at 10:49 AM, Bill Somerville
<[email protected] <mailto:[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]
<mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
<mailto:[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
