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
Attachment:
signature.asc
Description: PGP signature