Message-ID: <595E8559.5040707@posteo.de>
Date: Thu, 06 Jul 2017 20:45:45 +0200
From: DK7FC <selberdenken@posteo.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
References: <15ca21dc75e-1e15-bcda@webprd-m105.mail.aol.com> <0f9558b4-457d-a395-58c9-7f9be3393cdd@sky.com> <4767d79f-2bf6-d838-bfd4-3e78102d6f5d@abelian.org> <510c15eb-b57a-0ebb-9037-1f83e0652cf2@sky.com> <933fcc32-d4c9-10cd-14b4-c179d66e27f9@abelian.org> <7ab80e0f-40d7-6b07-19c1-f4b256d47c52@sky.com> <a9c1a7cc-d835-fb85-1ae4-1682303d0c39@abelian.org> <594DB217.8060707@posteo.de> <2eb826d6-d299-7b37-cf64-f5bef6718f24@abelian.org> <e1b35334-bee0-19e3-c923-e448181ef608@abelian.org> <595E4420.7060405@posteo.de> <alpine.DEB.2.11.1707061915380.714@mailn.lipkowski.org> <ac5cf362-22db-d073-23ce-88a0d454a37b@abelian.org>
In-Reply-To: <ac5cf362-22db-d073-23ce-88a0d454a37b@abelian.org>
Subject: Re: LF: Octo-soundcard for the Raspi, another question
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Status: RO

Hi Paul,

Thanks for the quick reply. Thanks for the hint regarding @raw:1,2,3. 
That will further help to reduce the CPU load. So you seem to confirm 
that the CPU usage is normal for what i have done.
I don't think that one of the channels are clipping but i will 
investigate. in SpecLab it show at -50 dB full scale, and the signal on 
CH1 is exactly the same as on CH2. The gain (alsamixer) is equal on all 
channels.
More later.

BTW there are local thunderstorm in quite a short distance. You asked 
for some a few months ago :-)
I'm listening to them on VLF, using vlfrx tools for the first time to 
listen to my stream from the tree using wget | vtvorbis @vlf and then 
vtfilter @vlf | vtraw | aplay...

73, Stefan

Am 06.07.2017 20:13, schrieb Paul Nicholson:
>
> Stefan wrote:
>
> > the CPU load of vttime and vtresample increases continuously to
> > very high values,
>
> Yes, vttime will be using most of a core, @raw is 8 channels and
> it's having to do a high quality resampling on them all.  If you
> only want 3 channels, use @raw:1,2,3 for input to vttime.
>
> vtresample we can't do much about, it already defaults to the lowest
> quality setting.
>
> > strangely the process number of vtwrite is lower than vtresample,
> > although vtresample has been started earlier.
>
> This is often the case when commands are run with -B option to
> put them into background.  Each command forks twice to detach
> itself from the controlling terminal.  When a pipeline is starting
> up, it's a race to claim process IDs as they're all forking.
>
> > channel 1 seems to show some minor glitches, see attachment.
>
> Looks bad.   Run the signal through vtstat -i to see
> if channel one is clipping at all.
>
>   vtread ... | vtstat -i
>
> Maybe both channels are close to hitting 1.0 amplitude in
> the stream and ch1 is slightly higher gain.  You need to
> look out for clipping if using integer sample formats.
>
> > had to call the vlfrx tools from /usr/local/bin into that
> > script
>
> As Jacek says.   cron runs its commands with quite a minimal
> enviroment, not quite the same as a login shell. For example it
> doesn't run .bashrc as would a login shell so any extensions
> to PATH or aliases wont be available unless you put them
> in the crontab or in the scripts run by cron.
>
> -- 
> Paul Nicholson
> -- 
>