Re: [linuxham] 100% cpu, and any chance of stereo output
>>>>> On Mon, 30 Jun 2008 23:59:12 -0000, "phluffy2002" <djch-linuxham@...> said:You shouldn't have to do anything special, as there is no busy waiting
> Two questions:
> I've been using fldigi with sdr-core and jack (and a softrock
> 6.2tx/rx), using oss2jack and the fldigi OSS mode. No problem, so I
> thought I'd try to simplify, and use portaudio direct to jack. It
> works, however fldigi (2.10.3) takes all the spare CPU (all the
> select() calls return immediately). It didn't do this with OSS. Is
> there some magic I've missed to avoid busy wait?
in fldigi's audio backend. Unless there's a weird bug somewhere!
I too have used fldigi with sdr-core and a softrock (rxtx v6.1). The
CPU load goes up, but it certainly doesn't reach 100% for a single
I just tested the latest svn revision of java-sdr with the (upcoming)
fldigi-3.0 code, and the load only climbed to about 25% on an old 2.8GHz
Pentium 4. About the same with fldigi-2.10.
Are you using the latest version of dttsp? Are the jack ports connected
correctly? Is jackd configured with a reasonable number frames per
period? Fldigi only uses the left input channel, so you might save some
cpu cycles by leaving the right channel disconnected.
> Quite separately, I get very odd results trying to get a clean txIsn't this (I&Q generation) what dttsp is for? IIRC, the sdr-core
> signal - imagine bpsk at 1KHz center in fldigi, but say +20 KHz in the
> sdr. I can tune out the -20 KHz image fine, but I get two sidebands at
> +- 1KHz around the center frequency, each about -20dB down. I wonder
> if it's because fldigi seems to only generate a mono output, and
> sdr-core wants an I&Q pair. Has anyone tried getting fldigi to emit
> I&Q - I'm happy to dive into the code, but I'd rather not duplicate
> existing work.
channels are as follows:
il, ir: i/q input from sound card
al, ar: accessory (non-i/q) input (mic or fldigi)
ol, or: non-i/q output (spk or fldigi)
tl, tr: transmit (i/q) output to sound card
Fldigi has two output channels, normally both carrying the same signal.
If you are using the CW QSK or RTTY pseudo-FSK features, that data then
goes to the right channel. As with the input, you probably want to leave
the right channel disconnected.