[pskmail] jpskmail 2.1.0-a
- From: Bob Morgan <wb5aoh@xxxxxxxxxxxxxxxxx>
- To: pskmail@xxxxxxxxxxxxx
- Date: Wed, 24 Jul 2013 16:30:47 -0500
I have found some kind of error from an interaction between jpskmail
and the pulseaudio volume control, if both are running at the same time.
Here is a paste of the error that gets thrown in the middle of the screen:
Sink input callback failure: Timeout
When this error window is closed, the volume control window is also closed down.
The timeout seems to take a minute or two to happen, while I am waiting on
jpskmail to send something every 5 minutes or so.
If jpskmail is started before the pa volume control, the volume control
window is blanked and never fills in with its contents. Only if it is already
running when jpskmail is started does it do anything, and after a minute or two,
things start to go wrong.
If I then happen to select the "recording device" choice instead of the output
device on the volume control, it throws errors immediately, and as I recall
it also muted the output and I had to bring the volume control app back up alone
just to un-mute the system so I could hear psk being generated again.
I couldn't document this behavior quite as well as the other one, but my
guess is they may be related or similar problems, and possibly jpskmail
might not have some coding it needs to answer an inquiry from a poll that
maybe pavu might be generating, and I think that there are also timers involved.
There are a couple of cosmetic observations for the jpskmail screen,
on the DSP display. First, the live refreshed black backgrounds of both
the waterfall and the phase scope are usually (although not always) displaced
downward and a little to the right of the static box outlines where they belong.
Otherwise they work fine as far as I can tell.
Second, the DSP display background is a different shade of color from the rest
of the
displays, and while it isn't a problem in that regard, they are the same color
as the dropdown menu background so it isn't obvious that it is a pulldown menu,
other than the text of the dropdowns just gets overwritten to what appears to
be the
DSP screen area, because they are the same color and the boundaries vanish.
I have been watching the system "busy" monitor display while pskmail is
running,
and of course it shows how the dsp process consumes cpu time, as I have seen
any dsp process behave. Nothing unexpected about that, dsp demod is a lot of
cpu work, and also not unexpected is that it is much easier to process dsp on
tx than
on rx. What I want to comment on is that if the waterfall/scope displays are
enabled,
rather than displaying the terminal or other window, is that the waterfall/scope
display is consuming more cpu resource than is the dsp rx process itself, and I
wanted to make sure you were aware of that (it also could vary from one system
to
another). Maybe it might not be necessary to update the dsp screen quite as
often,
but you would have to experiment with it to see how often or how seldom it needs
a screen rewrite before the user will miss the display updating. I experimented
a little bit with the "slow" checkbox to see what it did, it appeared to knock
maybe 5-10 percent off of the cpu load in the slow position, and I couldn't see
how much effect it had on the waterfall (the test environment here only includes
a microphone, not a radio at the present time).
I am running this on both a desktop and a laptop. The desktop is at work and
has
good access to the internet and no ham radio gear, and the laptop has spotty
connectivity
to the internet (right now it isn't readily accessible), and has potential to be
part of the ham gear either fixed or mobile. Both are ubuntu 12.04 lts systems,
and are more or less regularly updated from ubuntu. I have had pure hell
keeping
java 7 loaded, the update process along with whatever I might happen to add in
the
way of other applications unrelated to jpskmail, keep forcing both systems back
to java 6,
and I spent a day or two just trying to get java 7 both reinstalled and actually
activated. The installer program spent a lot of time lying to me as to whether
or not it was really installing or removing either or both, and most of the
time java 6
was in control of the system, which means that jpskmail would never start and
run.
Last month I posted a question about why I got some errors trying to run
jpskmail,
and I have since determined that this was most of the problem I was having,
and I still haven't got the laptop set up correctly since it has such spotty
access to the net here lately. In case other users weren't aware of the
behavior
of some systems, I wanted to document this behavior. I DID stumble onto
a java commandline (just a shell script) that is supposed to allow the user
to list/select which java version is actually pointed to at any time, and that
is:
sudo update-java-alternatives -l
sudo update-java-alternatives -s [your desired choice from the list goes here]
then do:
java -version
and maybe also have a look at:
ls -l /usr/lib/jvm/
ls -l /etc/alternatives/j*
to see what is being pointed to, whether or not it is really there, and so
forth,
then try running jpskmail to see if it runs.
One of these days I hope to have jpskmail sufficiently installed so that
I can actually try it out on the air, so far I am not there yet, but don't
want to give up on it now. Prior to pskmail using its own modems I wasn't
having any luck getting the fldigi/pskmail combination to behave and I was
spending most of my limited time tinkering with fldigi not jpskmail, and I
think I can
say I appreciate you using your own version of the modem and tying down
the interface between the two. I still like fldigi, but right now it is
just a separate test tool, and that interface has to work or nothing works.
I hope I am experimenting on the latest version, but I am not quite sure,
and I got a little confused on some of the version numbers the last time I
looked.
I gained access to a borrowed raspberry pi last week, and I am interested in
knowing if jpskmail (either client or server) can really run on it, I have read
that maybe, or maybe not, depending on whether or not it has enough processing
power to actually get the dsp work done in real time. I would like to hear
if anybody has done so successfully, and if so how they did it.
73 de Bob WB5AOH
Austin Tx
Other related posts:
- » [pskmail] jpskmail 2.1.0-a - Bob Morgan
