[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] RE:Linrad 01.20 Problem
- Subject: [linrad] RE:Linrad 01.20 Problem
- From: Leif Asbrink <leif.asbrink@xxxxxxxxxxxxxxxxxxxx
- Date: Fri, 4 Jun 2004 03:03:23 +0200
> I see about 4% CPU utilization
> and in the
> mono mode it works fine. If I try to use any of the two channel outputs
> such as coherent processing I have problems. The CPU still
> reads about 4%
> but the audio is chopped up badly like the processor can't keep up or is
> having to spend to much time doing something else? I have the same
> results running linrad in a console in x windows or from a
> commmand prompt from run level 3.
> Any one have any ideas what I'm doing wrong?
The timing in Linrad is a bit complicated:-)
The total delay time is the sum of the delay in the different
processing steps plus the delay caused by the amount of data
waiting in the output buffer. The delay caused by the CPU in actually
calculating results is small.
I do not think you are doing anything wrong, probably there is
some error in how Linrad estimates the amount of data to put
(on the average) in the output buffer. There is a parameter
"output delay margin" that you can increase to compensate for
errors of this kind. This parameter is primarily intended
to allow for some extra delay in case a very slow cpu is used.
Press "T" when running in the different output modes.
You will see how much delay you have in the different
processing steps. Possibly you have selected a baseband
filter in too many points. There is nothing wrong
with that except that it causes very long delay times and
maybe the need for some extra output delay margin.
The filter is made in the frequency domain. If you select
a filter with a bin resolution of 0.2 Hz you need a FFT that
spans 10 seconds (sin squared window). Before computing the output
you then have to collect data that spans 10 seconds. If the
"first mixer bandwidth reduction" is small, the 10 seconds
correspond to many samples causing the transform to be very
large. Then it may happen that the computing time becomes
long enough for the actual processing to take a longer time
than the default output delay margin. Stereo is of course
a bit slower than mono....
If the above does not help to locate the error, please
take down the numbers that "T" generates in mono and stereo
and send it to me (or the list). You may have detected
an error of some kind. Linrad-01.20 contains some modifications
to the delay computations because with 01-20 there is an
option to allow delay in the second AFC.
Leif / SM5BSZ