How about this:
There's no reason the signal viewer needs to be synchronous with the
audio stream. It can run async and read out of the circular buffer of
audio samples which is also used by the history function. PSK decoding
can run faster than realtime on just about any CPU that fldigi runs on
today (we'll skip embedded devices) so you have time left over for
another scan. One option is to scan a second time with PSK using a
different algorithm (for example, comb using fixed centers and look for
N successful phase transitions on 100 Hz centers the first time, then
again offset by 50 Hz the next scan).
But another option is to scan for PSK and other modes simultaneously.
Not everybody will want this, but it's ideal for some situations.
If you have a multi-core system such as an Athlon Hex-core, then this
scanning can be threaded, and all can run off the circular buffer
simultaneously. There's a little bit of synchronization so you probably
want to make a copy of the buffer at the beginning of each run, but in a
fast multi-core system that won't be that expensive. Then, run the mode
decodes in parallel in separate threads.
So, with a slight change from synchronous sample-push-through decoding
to one where the viewer asynchronously reads, you gain the freedom to
try different algorithms for PSK on some machines and to do multi-core
decoding on others.
And, I'll put in a plug for my idea (which I'm working on in the
background) of looking at the decoded output to see if there's signal,
based on ngrams and letter analysis.
Leigh/WA5ZNU
_______________________________________________
fldigi-alpha mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/fldigi-alpha
