[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fast computers.

Hi All,

In the old days (not many years ago) the processing power 
of computers was a limiting factor. Soundcards were designed
to be run at the lowest speed compatible with the desired
bandwidth for example. Nowadays, many soundcards sample 
at 48 kHz only and rate conversion (if desired) is done 
in the PC.

Linrad up to 02-43 was written for a slow speed loudspeaker
output. When setting 48 kHz for the output speed, the
fractional resampler consumed a ridiculously large fraction
of the total CPU time. That is no problem at all on modern
computers today, but with wider bandwidth for the receiver
like 1 MHz sampling rate from the Perseus, CPU time again may
become of some interest - particularly if one wants to run 
a transmitter in Linrad at the same time.

Linrad-02.44 will have an efficient up-sampler that can 
use simple 48 kHz soundcards for the loudspeaker efficiently.

An unexpected problem I have encountered with 02-44 was crashes
when clicking something in the baseband window. As it turned out
this was a bug which has been present in all Linrad-02.xx versions
up to now. The problem has been invisible because of the slow
output resampler, but now, with a fast one, the thread that
writes to the soundcard device is no longer safely waiting on
a semaphore, it may also hang on the write statement waiting
for data to flow into the loudspeaker. Rearranging memory
then is a bad idea, but that is what happens with this bug.

I do not have any really fast computer, but I guess the bug 
would cause crashes (segfaults) in case a really fast computer is 
used with any Linrad-02.xx under Linux. The risk is probably
larger when the output sampling rate is high and when the 
number of bytes per sample is high (2 channels x 2 bytes)

In order to fix this problem Linrad-02.44 is restructured
and I have removed all sorts of fixes that were added in 
the past to work around various bugs in old sound drivers.
As a result the code is more straightforward. The changes
affect the timing and the delay from antenna to loudspeaker
so I have to make many tests to see that things work
well on various combinations of hardwares and softwares.

One of the test results might be of immediate interest.
The soundcard I have been using for quite some time, a
SBLive, does not work well at 8 kHz with 1 channel and 8 bit 
output. The reason is that OSS allocates a fixed fragment size
(dma buffer) of 4096 bytes. As a consequence, each write
corresponds to 0.5 seconds and therefore the antenna to 
loudspeaker time delay becomes 0.8 to 1.3 seconds when everything
is set for fastest response. The time delay that Linrad can
extract from the soundcard is quantizised in steps of 0.5 

When running 2 channels and 16 bits the quanta become 125ms
at 8 kHz which is usually OK, but at 48 kHz it is down at 21ms
which is almost acceptable.

The long delay in OSS with the SBLive is present in oss 4.0-1012
as well as in oss3994e, but the old version oss395d which I use
with Mandrake 8.0 only allocates 256 bytes so worst case timing
is 32ms at 8kHz.

I have now inserted a SoundBlaster Audigy LS into the computer.
The oss driver for this card allows Linrad to set the buffer
size with the ioctl command SNDCTL_DSP_SETFRAGMENT just as the
buffer size can be set for the Delta44. Linrad will set a delay
in the soundcard buffers of 0.7ms (interrupt rate 1.5kHz) when
the user asks for the fastest possible processing. The delay
from antenna to loudspeaker is then about 40 ms in the current
state of what will be 02-44, but it should be possible to make
this delay about 25 ms with some code refinements. This is with
svgalib. Under X11 the delay is much larger for reasons I know
nothing about at this time. (I have not yet made any tests under

Summing up:
If you see long time delays, the reason can be in the soundcard
driver. This will show up as a large MIN for the D/A delay time
(Press "T" to see it)

Very fast computers may crash with segfaults if you change some
settings in the baseband window. Right click the signal to
disable output, then change and finally left click on the
signal to avoid these crashes in case they happen too often. 


Leif / SM5BSZ


You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad-unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad