Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
Title: Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal Hello Fons, Sunday, January 16, 2022, 1:01:32 PM, you wrote: > But in this case the audio interface is used to transfer signals to/from the > rig, so why should it ever become 'unavailable' during operation ? as an example, you start WSJT-X and your screen with an built-in audio is already 'active. Windows 'enumerates' the audio channels. The screen is audio channel number '1' since power on, WSJT-X will be using audio channel '2'. Now your screen goes to sleep mode - audio channel number '1' is gone. In fact, there is now only one audio channel, but WSJT-X software, still in the settings after startup, want to use audio channel '2'. So the pointer for channel '2' (in the settings of WSJT-X) can not find any hardware = your rig is unavailable. 73 de Wolfgang OE1MWW -- under construction: https://www.oe1mww.work/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
On Sat, Jan 15, 2022 at 11:17:58PM -0800, Paul Kube via wsjt-devel wrote: > On Fri, Jan 7, 2022 at 1:25 AM Fons Adriaensen via wsjt-devel > > > So does this mean that when a new audio device becomes available > > while a music app is playing some file, the output from that > > app would be redirected to some other device ? > > > > No, rather it seems to be a result of what happens when an audio device in > use becomes unavailable. For example, headphones get unplugged, or an HDMI > monitor goes into sleep mode, etc. Then it kind of makes sense that Windows > would try to find another device that applications can use. Of course, it > does this badly, not always correctly restoring connections when the device > becomes available again. But in this case the audio interface is used to transfer signals to/from the rig, so why should it ever become 'unavailable' during operation ? > Isn't the real issue here that WSJT is opening and closing the audio > > devices again and again for each RX or TX cycle ? > > I don't think so; have you looked at the source code, or traced audio > subsystem calls? :-) I'm not a WSJT dev, so just finding all the right places in the huge code base in order to answer that question with any degree of certainty would probably take a very long time... But surely the devs should know how they are using the audio interface. If they are indeed opening and closing the audio device in each cycle then I'm pretty sure that is the source of the problem. Ciao, -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
On Fri, Jan 7, 2022 at 1:25 AM Fons Adriaensen via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > On Thu, Jan 06, 2022 at 09:48:22PM -0800, Paul Kube via wsjt-devel wrote: > > > Any change to audio device availability on MS Windows is likely to > renumber > > the indexes of other devices, when this happens WSJT-X gets no > notification > > that it has happened. > > So does this mean that when a new audio device becomes available > while a music app is playing some file, the output from that > app would be redirected to some other device ? > No, rather it seems to be a result of what happens when an audio device in use becomes unavailable. For example, headphones get unplugged, or an HDMI monitor goes into sleep mode, etc. Then it kind of makes sense that Windows would try to find another device that applications can use. Of course, it does this badly, not always correctly restoring connections when the device becomes available again. Isn't the real issue here that WSJT is opening and closing the audio > devices again and again for each RX or TX cycle ? > I don't think so; have you looked at the source code, or traced audio subsystem calls? 73, Paul K6PO > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
Having an issue with latest 2.54 Windows 10, 64 bit. The program works great until time to log the contact, at which point the program continues to run in the background, but the logging window is frozen, immovable, and the only way to get out is to resort to the Task Manager. The system sound occurs with each mouse click, and the other windows of the program are inaccessible but still receiving. Thanks, and 73 Art KD0GY On Fri, Jan 7, 2022 at 4:14 AM William Smith via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > Only apps using the QT framework appear to have this problem. > Unfortunately, without rewriting wsjt in some other framework, it's hard to > solve. > > I'd think that adding the resync to the error process (when you pop up the > "audio failure" window, resync the audio numbering) would work, but I'm not > competent to do this myself, so I can't say how hard this Simple Matter Of > Programming might be. > > I suggested the 'resync audio' button solution a while back, but it didn't > get much traction. > > I'm using Linux on a Raspberry Pi, and it doesn't have this issue. Not > that that helps much, as most folks are running Windows. > > There are ways to prevent prevent triggering of the renumbering process in > Windows, but they are complicated, many-faceted, and fragile. > > #NoEasyAnswers > > 73, Willie N1JBJ > > > > On Jan 7, 2022, at 4:50 AM, Fons Adriaensen via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > > > > So does this mean that when a new audio device becomes available > > while a music app is playing some file, the output from that > > app would be redirected to some other device ? > > > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
Only apps using the QT framework appear to have this problem. Unfortunately, without rewriting wsjt in some other framework, it's hard to solve. I'd think that adding the resync to the error process (when you pop up the "audio failure" window, resync the audio numbering) would work, but I'm not competent to do this myself, so I can't say how hard this Simple Matter Of Programming might be. I suggested the 'resync audio' button solution a while back, but it didn't get much traction. I'm using Linux on a Raspberry Pi, and it doesn't have this issue. Not that that helps much, as most folks are running Windows. There are ways to prevent prevent triggering of the renumbering process in Windows, but they are complicated, many-faceted, and fragile. #NoEasyAnswers 73, Willie N1JBJ > On Jan 7, 2022, at 4:50 AM, Fons Adriaensen via wsjt-devel > wrote: > > So does this mean that when a new audio device becomes available > while a music app is playing some file, the output from that > app would be redirected to some other device ? ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
On Thu, Jan 06, 2022 at 09:48:22PM -0800, Paul Kube via wsjt-devel wrote: > Any change to audio device availability on MS Windows is likely to renumber > the indexes of other devices, when this happens WSJT-X gets no notification > that it has happened. So does this mean that when a new audio device becomes available while a music app is playing some file, the output from that app would be redirected to some other device ? I can't imagine this to be so, such a system would be unusable. Isn't the real issue here that WSJT is opening and closing the audio devices again and again for each RX or TX cycle ? Then the solution is to not do that: open the devices once and keep them open for as long as the programs runs. So don't stop the output stream during RX, just output silence. During TX keep reading the data from the audio input and discard it. -- FA ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] The #$&% Windows 10 audio issue, and a proposal
The problem is well known. As Bill G4WJS put it: Any change to audio device availability on MS Windows is likely to renumber > the indexes of other devices, when this happens WSJT-X gets no notification > that it has happened. That's an awful way to run an audio subsystem, and I'm sure it annoys more than WSJT-X users, but we're not likely to get Microsoft to change it. Bill goes on: There is no practical solution that I am aware of, we get a device index > when we initially enumerate the available devices and that index is used to > address the selected device to send or receive audio samples. Short of > re-enumerating audio devices just before any significant action with audio I > don't see a solution. Note re-enumerating takes time which we do not > usually have at the point it would be necessary. I suppose Bill is right that you don't want always to automatically re-enumerate devices before each transmit cycle "just in case". But let me suggest a practical partial solution. There are two ways at present to force a WSJT-X re-enumeration of audio devices that I know of: (1) Kill and restart WSJT-X, or (2) Switch WSJT-X to another Configuration, and then switch back. Both of these really take too much time, but then they are doing a lot more than just re-enumerating the audio devices. So my suggestion: add a *Reset Audio* menu item (under File or Tools, say) that lets the operator manually trigger audio device re-enumeration, and nothing else, when needed. Should be fast! A small thing, sir, but my own. 73, Paul K6PO ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
