[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] From the top down (inexpensively); Re: [linrad] Re: CPU-load and delay on 486
At 48 kHz output sampling speed it is very different. The routine becomes
ridiculous. The interpolation formula is used for each data point
in the output data stream:-( Absolutely stupid!!!
The purpose of the routine is to allow non-integer resampling rates
to permit non-synchronous audio cards for input and output. The
routine will produce a low distortion audio signal, something
that might be essential. Fitting a second order polynomial would
produce audible distortion on a noise-free sinewave.
Obviously an FFT should have been used to fit a sine-wave over a
couple of points. That sinewave could then be used to take samples
from at any desired output rate.
Another thing is that the BFO uses the sine and cosine functions of
the C library (presumably the processor) to shift the frequency
from zero to 400Hz or whatever the operator asks for. This is also
ridiculously slow if you go for 48kHz and there is no reason for
it because the BFO could be generated by phase increments through
multiplications.
Under normal operating conditions the carelessnes described above
is totally insignificant.
Another thing is that 'Linrad' development has not been linear
through the years, meaning that Leif has reported several times
that the code has been substantially improved.
Hmm, I would say it has been very linear. Like a good 3 bit A/D
converter;-) I have added new functions one by one, but once
added and coarse debugged, established functions are essentially
unchanged.
Therefore it may be that some listed values are not valid
anymore for the newest lir01-xx series
I do not think so. The total CPU load has been too high
on some systems occasionally due to various bugs but the
actual CPU use is not different over time.
(Leif, if that is what you mean by "too much"
information, then I could possibly agree, but there is a risk
to lose other embedded information if these old reports would
be removed; I guess the best is to display clearly the time
frame and technology/software versions during measurement).
No. I referred to my habit of giving alternate solutions on
each problem - seems that many people want to know "the one
and only good solution" (just think about how X-yagis are
used on 144 MHz.......)
Finally the (not so hypothetical) question is. Given a 486/33,
what is the approximate CPU load and delay with input sampling
at 48000 and output at 6000?
I do not think you can sample at 48 kHz with such a machine.
I would suggest 6000 for input and 5000 for output (if you can)
The delay is small - it is not much related to the processor.
My experience was that the screen
update was very sluggish initially in the lir00-xx series. So
possibly the main improvement has been there.
Yes. I made many changes motivated by various timing issues.
I think late versions handle priorities reasonably well. It
will skip screen updates in a way that you can hardly notice
in case there is a shortage of CPU time.
Also ISA-cards
seem to slow down the CPU during transfers (a DMA issue)? For
passive monitoring I would allow several seconds of delay, but
for regular QSO's one second is about maximum, dependent on the
mode.
????????
I have never seen anything like this.
Is it really something you have seen with Linrad?
Just remember, if you want a filter that is flat over 18 Hz
and that drops by 6 dB for a 20 Hz bandwidth, that filter has
a Q that makes the delay about one second.
For a short delay, expand the baseband graph and put only three
yellow points on the passband. The filter will then have a
"normal" Q and a much shorter delay.
It is not computing - it is just math;-)
73
Leif / SM5BSZ
#############################################################
This message is sent to you because you are subscribed to
the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to <linrad-request@xxxxxxxxxxxxxxxxxxxxx>
LINRADDARNIL