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