[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] 'Linrad'-philosophy (future features); Re: [linrad] Re: Abit IC7 allows 192kHz settings
This has been a very full day. I can't remember if it was posted that Leif has graciously found room for the Knoppix CD iso file on the sm5bsz.com server.
I am busy reworking / shrinking / 'fixing' the iso before uploading it to sm5bsz.com.
I think I found the answer I think to Zaba's 'disappearing directory' problem, and why I see files and directories in the root directory here that Zaba says he doesn't see. A quote from somewhere in 'Knoppix-ville' that I ran across this evening:
"Knoppix automatically overwrites the directory /home/knoppix with /etc/skel during boot".
So I think that the files that I had carefully placed in /root for users-san ended up in /home/knoppix/root with the Knoppix-Live CD boot process, and then got overwritten.
The delay in upload for the iso file is caused by my trying an alternate strategy, making an iso file and then a CD with it, trying it, and then going back for round 2 etc to correct my mistakes. It takes about an hour per cycle, and I just broke free to start this after 10 pm, so the uploaded iso may not appear before sometime late tomorrow. I will announce when it is uploaded.
I have decided I need yet another computer, to contain ONLY an experimental, deletable Knoppix hard-disk installed system, to look for these bugs which don't appear if the testing is on the system with the permanent reference install. I will see if any of wife/children can give up their computer for this noble purpose [only kidding, I am not that stupid ;) ].
73, all with my apologies for the delay...
Roger
W3SZ
Leif-san,
Multi-threading keeps you busy and hopefully you have
received expert advice for some of your questions....
I have now understood that the CPU is not determining
the delay in 'Linrad', but rather: the slower the CPU,
the higher its relative usage, until it reaches 100%..
Then the application probably "collapses"... a rare
occurrence with today's fast processors.
All of the integrated audio on several motherboards
"propose" a sample rate choice up to 48000, except the
Abit IC7 (proposing choices up to 192000). It does not
mean that one can build an I/Q-receiver with successful
utilization of the full bandwidth. Actually the IC7 is
the worst quality board (compared to all others here)
regarding the operation of the integrated audio circuit
(at least as far as the microphone input is concerned).
For example under Skype VoIP-communications there is a
strong tapping noise on the outgoing audio, and under
'Linrad' the input spectrum shows wide noise bands at
7 kHz and 41 kHz on the frequency spectrum when using
48000 sampling rate (when no input signals are fed).
All of this may be better on the line input (however
not tested). Also another main power supply should be
tried to ensure that all MB-voltages have been clean.
As Leif/SM5BSZ suggested, some audio cards can be set
beyond their specs to give the CPU some more samples
and a bigger work load. So the sampling rate of the
integrated audio of the Abit IC7 was set to 192000
and the output rate to 8000 Hz. With a 2400 MHz P4
this resulted in about 26% CPU-load, and with the
inefficient Lagrange-interpolation under 192000 Hz
output sampling, the load was 36%. I do not know what
the extra load is for 4-channel operation, but probably
this setup could process future 8-channel 192 kHz input
sampling if the output rate is limited to the low rates.
When feeding audio to the IC7 input, it was clearly seen
that the circuitry was not designed for these high rates
as the input spectrum showed multiple aliased responses,
and the baseline level dropped off above 24 kHz separation
form the center frequency. Also I noticed that the 'Linrad'
frequency scale of the waterfall behaves like an old car's
mileage meter, showing 100 000 as 00 000 (actually just 0).
So the parameter needs an allocation for one more figure
on the right end of the scale: e.g. 140000 Hz now 40000 Hz.
Initially this was a little confusing, but the experiment
yielded this improvement suggestion for the user-interface.
As such all these experiments have again derailed me from
the goal to get some form of real world reception ability.
Thus it is about time to link up some of the analog stuff
in front of the sound inputs. That is actually the best
incentive to learn about the use and optimization of the
various parameters. The impulse generator for the quick
calibration of the I/Q-channels (and the smart blanker)
is actually not too complicated, but here its construction
has been delayed already for years, due to all the other
"interesting" 'Linrad' experiments and software challenges.
A key for quick successful results would be an "approach
guidebook" that should be fairly strictly followed. The
ongoing Live_CD development by Roger/W3SZ will certainly
speed up the start-up time of new candidates (by 10 dB).
73, "Zaba" OH1ZAA/2 [The sky is no limit]
At 19:28 26.4.2005 +0200, SM5BSZ wrote:
>Hi All,
>
>In the current Linrad package, the CPU spends its
>surplus time in an "idle loop" which is just doing
>nothing or sending the process to sleep with usleep();
>depending on the parameters selected by the user in
>the initial setup.
>
>Just by comparing the time spent in the idle loop
>to the total time one gets a good number for how much
>of the time available to Linrad that could be used for
>heavier processing.
>
>In the multi-threaded version the above strategy is
>not possible. Any time not needed by Linrad is consumed
>by the kernel or another task. Instead a system call
>getrusage() is used to get the total amount of time
>that the CPU spent with the task. This works fine
>with the 2.6 core and is how getrusage is defined
>according to POSIX (whatever that is) but in the 2.4
>and older kernels getrusage works differently. It
>just gives the time consumed by the calling thread
>and therefore all threads have to be interrogated.
>This is fine in the development phase because it
>allows me to see where the time is spent, but summing
>over the fifteen threads which gives the correct load
>under 2.4 kernels gives a value that is too big by 15
>times under 2.6.
>
>By setting a global define GETRUSAGE_OLD to 0 or 1
>Linrad works fine under both kernels. Currently
>a header file has to be edited manually, but I am sure
>it is possibe to use the configure script to find out
>which of the behaviours to implement at compile time.
>Presumably it amounts to find the GCC version and make
>a test on it to get a yes or no answer.
>
>I just do not know how to do it. Is there anyone on the
>list who knows? I do not understand anything about how
>the configure script really works - someone made it for
>me - so I really need a few lines to add to the Linrad
>configure.in file to get an input to AC_SUBST.
>
>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>
#############################################################
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