Bug#995198: wsjtx: No transmit audio

[Hilary Snaden]

Package: wsjtx
Version: 2.5.0~rc6+repack-1
Severity: important
X-Debbugs-Cc: hilary...@zoho.com

Dear Maintainer,

The program generates no audio output on transmit, in any mode. This is identical to a bug which I reported on the previous version of wsjtx, under Debian bullseye/sid (though on different hardware).

The program works satisfactorily on receive.

The similar (in function) program fldigi generates good, clean audio on transmit on the same machine.

- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wsjtx depends on:
ii libboost-filesystem1.74.0 1.74.0-9
ii libboost-log1.74.0 1.74.0-9
ii libboost-thread1.74.0 1.74.0-9
ii libc6 2.32-4
ii libfftw3-single3 3.3.8-2
ii libgcc-s1 11.2.0-7
ii libgfortran5 11.2.0-7
ii libgomp1 11.2.0-7
ii libhamlib-utils 4.1-4
ii libhamlib4 4.1-4
ii libqcustomplot2.0 2.0.1+dfsg1-5
ii libqt5core5a 5.15.2+dfsg-10
ii libqt5gui5 5.15.2+dfsg-10
ii libqt5multimedia5 5.15.2-3
ii libqt5multimedia5-plugins 5.15.2-3
ii libqt5network5 5.15.2+dfsg-10
ii libqt5serialport5 5.15.2-2
ii libqt5sql5 5.15.2+dfsg-10
ii libqt5sql5-sqlite 5.15.2+dfsg-10
ii libqt5widgets5 5.15.2+dfsg-10
ii libstdc++6 11.2.0-7
ii wsjtx-data 2.5.0~rc6+repack-1

Versions of packages wsjtx recommends:
ii wsjtx-doc 2.5.0~rc6+repack-1

wsjtx suggests no packages.

-- no debconf information

[tony mancill]

Hello Hilary,

On Mon, Sep 27, 2021 at 09:07:49PM +0100, Hilary Snaden wrote:
> Package: wsjtx
> Version: 2.5.0~rc6+repack-1
> Severity: important
>

> Dear Maintainer,
>
> The program generates no audio output on transmit, in any mode. This is identical to a bug which I reported on the previous version of wsjtx, under Debian bullseye/sid (though on different hardware).
>
> The program works satisfactorily on receive.
>
> The similar (in function) program fldigi generates good, clean audio on transmit on the same machine.

I am not experiencing any problems with transmit with this version of
wsjtx. Can you provide more details about your configuration and/or
hardware?

Thank you,
tony

[tony mancill]

I believe I encountered the same behavior you are reporting with wsjtx
2.5.0+repack-1. wsjtx receives audio as expected, but nothing is
generated during transmit or tune, and PTT (via CAT for my rig) doesn't
even switch my radio into TX.

This same version and configuration of wsjtx worked correctly a week
ago. I run testing/unstable and update every few days, so my initial
thought was that the change in behavior was due to an apt update of the
system.

I tried reconfiguring and reinstalling wsjtx, and then uninstalling
pulseaudio, to no effect. However, rebuilding wsjtx against unstable in
a clean chroot and installing the resulting deb results in a fully
functioning wsjtx again.

At this point, I couldn't tell you whether it is library dependency of
wsjtx or something in the build environment that has changed and is
addressed by the rebuild. However, it is reproducible - meaning my
locally build .deb works consistently, and reinstalling the .deb from
the archive (I believe generated by this build [1]) fails to generate TX
audio.

I am tempted to upload a new source package to trigger a rebuild to see
if that solves the problem with the deb in the archive. Perhaps wsjtx
got caught up in a transition causing this subtle failure?

Christoph or Dave, do you have any suggestions on how to track down the
root cause?

Thank you,
tony

[1] https://buildd.debian.org/status/fetch.php?pkg=wsjtx&arch=armhf&ver=2.5.0%2Brepack-1&stamp=1632820833&raw=0

[Christoph Berg]

Re: tony mancill

> I am tempted to upload a new source package to trigger a rebuild to see
> if that solves the problem with the deb in the archive. Perhaps wsjtx
> got caught up in a transition causing this subtle failure?
>
> Christoph or Dave, do you have any suggestions on how to track down the
> root cause?

Since it works for me I don't have any idea how to debug this, except
maybe to diffoscope the two debs.

No objections to trying a rebuild of course.

> [1] https://buildd.debian.org/status/fetch.php?pkg=wsjtx&arch=armhf&ver=2.5.0%2Brepack-1&stamp=1632820833&raw=0

Maybe the problem is architecture-specific? The OP is on amd64 like
me, though.

Christoph

[tony mancill]

On Sun, Oct 17, 2021 at 11:56:35PM +0200, Christoph Berg wrote:
> Re: tony mancill
> > I am tempted to upload a new source package to trigger a rebuild to see
> > if that solves the problem with the deb in the archive. Perhaps wsjtx
> > got caught up in a transition causing this subtle failure?
> >
> > Christoph or Dave, do you have any suggestions on how to track down the
> > root cause?
>
> Since it works for me I don't have any idea how to debug this, except
> maybe to diffoscope the two debs.

That's a good idea. The diffoscope results in 100MB of diff, almost all
of it in the resulting binaries, so I'm opting to focus on the build
environments for now. There are a number of differences, most of which
appear to be benign. The only significant ones are the GCC-10 -> GCC-11
transition and hamlib 4.1 -> 4.3

If anyone would like to take a look at the buildinfo from the archive
and locally build packages or the full diffoscope between the binary
packages, those files can be found here:

https://people.debian.org/~tmancill/wsjtx-995198/.

> No objections to trying a rebuild of course.
>
> > [1] https://buildd.debian.org/status/fetch.php?pkg=wsjtx&arch=armhf&ver=2.5.0%2Brepack-1&stamp=1632820833&raw=0
>
> Maybe the problem is architecture-specific? The OP is on amd64 like
> me, though.

Yeah, I was surprised when it occurred for me. Of course, I'm making an
assumption that the behavior I saw is the same as that from the original
bug report.

The fact that the "Tune" button couldn't even key my radio, despite the
fact that I'm using CAT, makes me suspect that I might have found a issue
with running a binary compiled against hamlib 4.1 against a system with
4.3 installed. That upload was on 2021-10-12, which would explain why I
didn't see it a week ago; I updated my system on 2021-10-16.

But that still doesn't explain why you didn't see the problem. Hmm...

Thank you,
tony

[Christoph Berg]

Re: tony mancill

> That's a good idea. The diffoscope results in 100MB of diff, almost all
> of it in the resulting binaries,

Uh, I guess that was to be expected... sorry for the naive suggestion.

> environments for now. There are a number of differences, most of which
> appear to be benign. The only significant ones are the GCC-10 -> GCC-11
> transition and hamlib 4.1 -> 4.3

wsjtx runs fine here with hamlib 4.3 when still compiled against 4.1;
I have not tested rebuilding yet.

> The fact that the "Tune" button couldn't even key my radio, despite the
> fact that I'm using CAT, makes me suspect that I might have found a issue
> with running a binary compiled against hamlib 4.1 against a system with
> 4.3 installed. That upload was on 2021-10-12, which would explain why I
> didn't see it a week ago; I updated my system on 2021-10-16.

Iirc there is some known issue with Tune interfering with audio
generation if you use the "wrong" button to abort the tune operation;
wsjtx wouldn't generate audio in the next cycle, but recover in the
2nd next cycle. I haven't observed that here lately, but maybe I just
haven't hit the Tune button enough. (There are probably reports of
that on wsjt-devel.)

The issue discussed here seems to be something else, but possibly they
are connected.

Christoph

[tony mancill]

On Mon, Oct 18, 2021 at 10:41:07AM +0200, Christoph Berg wrote:
> Re: tony mancill
> > That's a good idea. The diffoscope results in 100MB of diff, almost all
> > of it in the resulting binaries,
>
> Uh, I guess that was to be expected... sorry for the naive suggestion.

I didn't think it was naive at all. I merely wanted to point out that
the differences are only in the build environments, and that I'm not
sure how to determine from the binary diffs whether they might
contribute to the change in behavior.

> > environments for now. There are a number of differences, most of which
> > appear to be benign. The only significant ones are the GCC-10 -> GCC-11
> > transition and hamlib 4.1 -> 4.3
>
> wsjtx runs fine here with hamlib 4.3 when still compiled against 4.1;
> I have not tested rebuilding yet.

I went ahead and performed another source upload and will test against
with the resulting binary from the archive.

> > The fact that the "Tune" button couldn't even key my radio, despite the
> > fact that I'm using CAT, makes me suspect that I might have found a issue
> > with running a binary compiled against hamlib 4.1 against a system with
> > 4.3 installed. That upload was on 2021-10-12, which would explain why I
> > didn't see it a week ago; I updated my system on 2021-10-16.
>
> Iirc there is some known issue with Tune interfering with audio
> generation if you use the "wrong" button to abort the tune operation;
> wsjtx wouldn't generate audio in the next cycle, but recover in the
> 2nd next cycle. I haven't observed that here lately, but maybe I just
> haven't hit the Tune button enough. (There are probably reports of
> that on wsjt-devel.)
>
> The issue discussed here seems to be something else, but possibly they
> are connected.

I wasn't able to reproduce that issue, and so I assume it is distinct
from the "no audio" issue with both Tune and a normal TX.

Cheers,
tony

[tony mancill]

On Fri, Oct 22, 2021 at 08:28:50PM -0700, tony mancill wrote:
> On Mon, Oct 18, 2021 at 10:41:07AM +0200, Christoph Berg wrote:
> > wsjtx runs fine here with hamlib 4.3 when still compiled against 4.1;
> > I have not tested rebuilding yet.
>
> I went ahead and performed another source upload and will test against
> with the resulting binary from the archive.

The archive-built binary package (2.5.0+repack-2) does not exhibit the
no-TX audio problem for me (on armhf).

Hilary would you be willing to try again with the updated binary?

Thanks,
tony

[Hilary Snaden]

You may need to point me towards it, I generally stay with repo packages
and appimages to avoid too much instability.

In the meantime I have tried wsjtx on the same machine with an external
sound card, and on an older laptop running bullseye/sid. There is no
transmit audio on any of them. Fldigi works, and wsjtx receive works,
with all three configurations.

Hilary

[tony mancill]

On Thu, Oct 28, 2021 at 07:39:32PM +0100, Hilary Snaden wrote:
>
> On 23/10/2021 19:12, tony mancill wrote:
> > On Fri, Oct 22, 2021 at 08:28:50PM -0700, tony mancill wrote:
> > > On Mon, Oct 18, 2021 at 10:41:07AM +0200, Christoph Berg wrote:
> > > > wsjtx runs fine here with hamlib 4.3 when still compiled against 4.1;
> > > > I have not tested rebuilding yet.
> > >
> > > I went ahead and performed another source upload and will test against
> > > with the resulting binary from the archive.
> >
> > The archive-built binary package (2.5.0+repack-2) does not exhibit the
> > no-TX audio problem for me (on armhf).
> >
> > Hilary would you be willing to try again with the updated binary?
>
> You may need to point me towards it, I generally stay with repo packages and
> appimages to avoid too much instability.

The version to test with is 2.5.0+repack-3. It us currently in unstable
and should be in testing sometime tomorrow or perhaps on the 30th.

You can check the status here:

https://packages.debian.org/sid/wsjtx

> In the meantime I have tried wsjtx on the same machine with an external
> sound card, and on an older laptop running bullseye/sid. There is no
> transmit audio on any of them. Fldigi works, and wsjtx receive works, with
> all three configurations.

This sounds consistent with the problem I experienced on my Raspberry Pi
and an IC-705 (which presents to the OS as an external USB sound card).

Cheers,
tony

[Hilary Snaden]

On 29/10/2021 03:12, tony mancill wrote:
> The version to test with is 2.5.0+repack-3. It us currently in unstable
> and should be in testing sometime tomorrow or perhaps on the 30th.
>
> You can check the status here:
>
> https://packages.debian.org/sid/wsjtx

Installed from the repo. Still no transmit audio.

[tony mancill]

That's a bummer, but thank you for confirming. I installed
2.5.0+repack-3 from the repo as well and TX audio is working for me.

A few random questions:

- What PTT method are you using?

- If you are using CAT to trigger PTT, does "Test PPT" actually switch
your radio into TX?

- Do you see any output on stdout or stderr when you invoke wsjtx and/or
try to transmit.

Thanks,
tony

[Hilary Snaden]

On 31/10/2021 17:15, tony mancill wrote:
> On Sun, Oct 31, 2021 at 12:39:50PM +0000, Hilary Snaden wrote:
>>
>> On 29/10/2021 03:12, tony mancill wrote:
>>> The version to test with is 2.5.0+repack-3. It us currently in unstable
>>> and should be in testing sometime tomorrow or perhaps on the 30th.
>>>
>>> You can check the status here:
>>>
>>> https://packages.debian.org/sid/wsjtx
>>
>> Installed from the repo. Still no transmit audio.
>
> That's a bummer, but thank you for confirming. I installed
> 2.5.0+repack-3 from the repo as well and TX audio is working for me.
>
> A few random questions:
>
> - What PTT method are you using?

Vox.

> - If you are using CAT to trigger PTT, does "Test PPT" actually switch
> your radio into TX?

The CAT on my rig stopped working after a voltage surge fried my
USB-serial interfaces. A new (USB controllable) rig is on my medium-term
wishlist.

> - Do you see any output on stdout or stderr when you invoke wsjtx and/or
> try to transmit.

None at all.

However, if I try to change the audio device (settings...) this appears:

Cannot connect to server socket err = No such file or directory

Cannot connect to server request channel

jack server is not running or cannot be started

JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
skipping unlock

JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1,
skipping unlock

ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp

ALSA lib pcm_dsnoop.c:600:(snd_pcm_dsnoop_open) unable to open slave

ALSA lib pcm_dsnoop.c:600:(snd_pcm_dsnoop_open) unable to open slave

ALSA lib pcm_usb_stream.c:503:(_snd_pcm_usb_stream_open) Unknown field hint

[Christoph Berg]

Re: Hilary Snaden

> The CAT on my rig stopped working after a voltage surge fried my USB-serial
> interfaces. A new (USB controllable) rig is on my medium-term wishlist.

Ouch :(

> However, if I try to change the audio device (settings...) this appears:
>
> Cannot connect to server socket err = No such file or directory
>
> Cannot connect to server request channel
>
> jack server is not running or cannot be started

That looks like Qt multimeda has trouble talking to pulseaudio.

Are you using pulseaudio? Is fldigi working properly through
pulseaudio, or talking to the sound devices differently?
(To inspect, start pavucontrol and check if the play/record channel
meters move on transmitting.)

I have no idea if wsjtx on Debian is supposed to work with Jack or
plain Alsa.

Christoph

[Hilary Snaden]

On 01/11/2021 22:11, Christoph Berg wrote:
> Re: Hilary Snaden
>> The CAT on my rig stopped working after a voltage surge fried my USB-serial
>> interfaces. A new (USB controllable) rig is on my medium-term wishlist.
>
> Ouch :(
>
>> However, if I try to change the audio device (settings...) this appears:
>>
>> Cannot connect to server socket err = No such file or directory
>>
>> Cannot connect to server request channel
>>
>> jack server is not running or cannot be started
>
> That looks like Qt multimeda has trouble talking to pulseaudio.
>
> Are you using pulseaudio? Is fldigi working properly through
> pulseaudio, or talking to the sound devices differently?
> (To inspect, start pavucontrol and check if the play/record channel
> meters move on transmitting.)

Yes.

> I have no idea if wsjtx on Debian is supposed to work with Jack or
> plain Alsa.

I may be missing something, but I don't see any reason for Jack to be a
dependency for this type of program. If Jack is installed, it can appear
as an audio option. If Jack is not installed, it needn't appear. It
seems that the current wsjtx looks for Jack anyway and complains if it
isn't there. This may be a different issue to the no-output bug, but it
suggests that there is room for improvement in the audio chain programming.

Hilary

[Christoph Berg]

Re: Hilary Snaden

> > > However, if I try to change the audio device (settings...) this appears:
> > >
> > > Cannot connect to server socket err = No such file or directory
> > >
> > > Cannot connect to server request channel
> > >
> > > jack server is not running or cannot be started

Hi Hilary,

is that problem still present?

Christoph