Hi Arkadiusz,
Thanks for your helpful bug report. I have removed this line. Also from
my point of view, it makes little sense and is even risky under certain
circumstances.
73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg2...@gmx.de
Info: www.qrz.com/db/DG2YCB
Am 22.09.2024 um 13:01 schrieb Arkadiusz Miśkiewicz via wsjt-devel:
Hello.
After upgrade from MacOS Sonoma to MacOS Sequoia (the rest of the
hardware/software setup is exactly the same) one thing has changed.
First wsjt-x transmission stops input audio.
Tests done on wsjt-x 2.7.0 rc6
Everything worked fine on MacOS Sonoma, so likely Sequoia changed
something that is a Sequoia bug or it triggers wsjtx bug.
It looks like this:
- starting the wsjt-x app, it receives audio, microphone icon appears
on macos menubar
- enable tx, transmission starts, microphone icon is there on menubar
for the whole transmission
- transmission ends, microphone icon disappears from macos menubar
- wsjt-x continues to try to decode incoming data but it can't do that
since it no longer receives the audio, 0dB on bar etc.
- changing anything in settings->audio recovers the thing (microphone
icon is back, wsjtx again sees and decodes incoming data). Probably
changing things there cause reopening of audio stream. Until next
transmission.
- in macos logs I see that macos report audio being closed but somehow
wsjt-x doesn't notice that
Now I've tracked that to this part of code (below).
Dropping m_stream.reset() call makes the problem on Sequoia go away.
I'm able to make multiple transmissions and input audio doesn't get
lost (microphone icon on macos bar is there all the time).
Audio/soundout.cpp
void SoundOutput::stop ()
{
if (m_stream)
{
m_stream->reset ();
m_stream->stop ();
}
m_stream.reset (); // <------- dropping this reset makes problem go
away
}
It was added in 2020:
commit 542ffe83112c16e9a56fe946c496c8b4973683ff
Author: Bill Somerville <b...@classdesign.com>
Date: Sun Sep 20 18:20:16 2020 +0100
Improve audio device handling and error recovery
The question is is that reset call correctly done there in that way
and the bug is in Sequoia or is it a wrong call?
Thanks,
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
