On Jan 27, 2009, at 7:37 PM, Rick Ruhl wrote:
> True Chen, but don't you think we'd have to do a Ring 0 lever driver
> to get
> access to the registers in the sound card? We could put all the dsp
> code in
> there (in asm) and poof, no latency at all.
No, that is why I mentioned the lack of need to even use ASIO (a low
latency sound driver that Steinberg developed because the Microsoft
sound interface has too much latency for pro audio work -- see,for
example
http://en.wikipedia.org/wiki/Audio_Stream_Input/Output .
As long as the sound card's sampling period is constant, the DSP does
not care about latency.
Imagine that I generate a voltage ramp from 1 volt to 8 volts,
changing by one volt each millisecond.
A codec running at 1000 samples/second would encode the voltage
waveform into 8 numbers, 1, 2, 3, 4, 5, 6, 7, 8.
It does not matter to the DSP code if these 8 numbers are sent to the
processor as
1, 2, 3, 4, 5, 6,7, 8
or
1, 2, <pause> 3, 4, 5, 6 <pause>7, 8
or as
1, 2, 3, 4, <pause> 5, 6, 7, 8
The 5th sample will still be the 5th sample to the DSP filter, which
assumes that the numbers started out in the codec with 1 msec spacings.
The only time it is important is that if the pauses add up so that the
stream no longer keeps up to real time.
But that is no longer a problem with today's processors. Take a look
at how many percent of processor MMTTY is using. cocoaModem runs 9
separate demodulators concurrently for RTTY and yet it does not use
more than about 10% of an old 2.3 GHz G5 machine.
Latency is a problem with tuning indicators, but not with actual
conversion of mark/space tones into Baudot characters.
73
Chen, W7AY
P.S. why 9 RTTY demodulators in cocoaModem? I have mentioned this
before but it might be salient to repeat it as long as we are talking
about comparing modems.
I am sure there are many of us who have seen a ST-8000 decode a
character wrongly while a lowly KAM Plus decodes it correctly. When
people say the HAL is better than the KAM, they mean that the ST-8000
is better on the average, not with every character. I.e., when you
compare the two modems, the better modem is not *always* right. It is
just right more times than the worse modem is right.
This effect is prevalent enough that from as long as I could remember,
many contesters run with two modems and keeping an eye on the output
of both modems.
If 2 is good, why not more? Well, your eyes and brain get tired very
easily.
In software, extra demodulators also cost nothing; it is not like you
have to shell out $4000 to HAL for each one -- I simply instantiated
more copies of a modem object (Obective-C is object oriented). What
cocoaModem does is to run 9 FSK demodulators behind your back, then
use majority voting (9 is an odd number by design) to decide which
character it prints to the screen. Each demodulator has a slightly
different ATC time constant and relative multipath delay. You don't
have to keep an eye on multiple screens or windows, the majority
voting module does it for you.
The majority is not always right of course, but they are right enough
times to make it worth spending all the extra processor cycles. This
also has an additional advantage that I use this for squelching. The
more demodulators have a character in common, the less the chance the
character is squelched away. The squelch slider is simply a value of
how many demodulators must agree for the character to print.
It is probably trivial to add to MMTTY, by the way :-). Just run each
demodulator with a slightly different "MMTTY parameter." Then use an
HF channel simulator to decide what sets of parameters you want to use.
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|