Yes, what Hranfnkell said...
If we have been keeping up with our Linux journals and news. We would
realize that Pulse is out, pipewire is in. Announcement made over 18
months ago. Debian following the Enterprise has implemented pipewire
with that strange pulse bridge for backward compatibility. I ran into
similar issues building some SDR packages. Just keep in mind that the
pulse bridge to pipewire will also be going away as updates happen. So
it's really time to consider updating the code, even QT, to support
pipewire.
On 11/5/23 12:38, Hrafnkell Eiriksson via wsjt-devel wrote:
The root cause of this all seems to be a bug in the interface between
pulseaudio (or the puseaudio interface for pipewire in Bookwork) and
Qt audio device handling.
After suspending the SoundInput the audio thread is stuck spinning in
a loop somewhere in the qt multimedia plugin for pulse and/or the
libpulse code.
This results in it hogging the CPU core so the modulator code never
manages to create output
The good news is that this only seems to happen if the output audio
device is selected as pulse (and possibly other devices that go
through pulse).
If I select the direct alsa device for both input and output this does
not happen and transmit and decode seems to work.
I at least learned a little how the wsjtx app is organized :)
73 de TF3HR
On Sun, Nov 5, 2023 at 3:53 PM Hrafnkell Eiriksson <h...@tf3hr.net> wrote:
And the reason for the 100% cpu load that prevents the audio out
from running seems to have something to do with the suspend() call
on the SoundInput. If I comment that out, nothing goes to high CPU
load.
Just disabling monitoring through the GUI (main window) is enough
to go to 100% cpu load on wsjtx.
Not sure why this happens...
73 de TF3HR
On Sun, Nov 5, 2023 at 12:52 PM Hrafnkell Eiriksson <h...@tf3hr.net>
wrote:
Splitting the work done by the m_audioThread in
widget/mainwindow.cpp into two threads, m_audioInThread and
m_audioOutThread also solves the problem and is probably a
better solution.
I've put the modulator and soundOutput on m_audioOutThread and
the detector and soundInput on the m_audioInThread.
According to top, both the wsjtx main thread and a second
thread (I'm guessing the audioInThread are both taking close
to 100% cpu). The core of the problem might just be that the
audio out part of the code was never able to run since the
other parts were fully utilizing the single cpu core the audio
was running on.When I split the work between two cores the
audio out code has a chance to run.
I'm basing my changes on commit
4667929d0e5a65569d3d0fbb331c4fd1cb1368b8 (HEAD -> master, tag:
wsjtx-2.7.0-rc2, origin/master, origin/HEAD)
73 de TF3HR
On Sat, Nov 4, 2023 at 9:14 PM Hrafnkell Eiriksson
<h...@tf3hr.net> wrote:
I've been trying to figure out why I get no audio output
on the Raspberry Pi and have found out that it seems to be
related to threading.
After liberal sprinkling of qDebug() in the code to see
what was happening and in what order things were called I
figured out that the Modulator code was never run after
pressing tune.
The first press of the Tune button will lead to the call
of Modulator::tune() but after that no code in Modulator
was run.
Repeated click on Tune would not result in the tune signal
being processed by Modulator::tune.
I then noticed that soundOutput, modulator, soundInput and
detector were all moved to the m_audioThread in
mainwindow.cpp.
After some trial and error I found out that by not moving
the m_modulator to the m_audioThread (commenting out
m_modulator->moveToThread (&m_audioThread);) would "solve"
the no-audio generated on Tune.
I can now press Tune repeatedly and always get sound in my
audio device.
I don't know if this is a proper solution.
Also, I can't find where the m_audioThread is constructed
in the code. Adding an initializer for it to construct it
in the MainWindow constructor does not help.
Hope someone who knows the code better than me can help me
in the right direction. This seems to be a threading
issue, priorities and/or a locking issue?
Thanks and 73
Hrafnkell TF3HR
On Sun, Oct 29, 2023 at 8:44 PM Hrafnkell Eiriksson
<h...@tf3hr.net> wrote:
Hi
I recently installed wstjx 2.6.1 on a RPi4 running an
up to date Bookworm version of the
Debian/RaspberryPI-OS. Wsjtx is installed from the
distribution repository.
I am unable to get it to output audio from wsjtx.
I've tried two different USB connected audio
interfaces, a DigiRig mobile and a Logitech PRO
headset (that comes with a usb to 3.5mm jack adapter).
I've tried selecting default audio streams in the
audio setup for output and the specific card stream
(e.g. hw:CARD=PRO,DEV=0). No audio is generated when
pressing the Tune button.
I've used pavucontrol to monitor the audio sources
generated and an output stream is never set up for the
wsjtx program. An input stream is visible in the
pavucontrol as "ALSA plug-in [wsjtx]" and audio input
works fine.
I've tried both the 64 and 32 bit versions of the
Bookworm distribution of RPiOS.
Any help would be appreciated in figuring this out.
Thanks and 73
TF3HR Hrafnkell
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
Jeff Stillinger - KB6IBB
KB6IBB Laboratories, Wylie Tx
r/KB6IBBSWLLogger
http://kb6ibb-15.ham-radio-op.net/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
