Re: [wsjt-devel] Hashed callsign collisions?
I would not be surprised if only the main call is used to compute the hash. Then this admittedly rare and apparently unforseen case, the same main call being used by multiple different stations at the same time, distinguished only by their slash "decoration", arises. Result: collisions among W1AW slash whatever calls. 73, Paul K6PO On Fri, Jan 20, 2023 at 1:46 PM George J Molnar via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > I had the same thing happen - as if the hash is the same for both /0 and > /7, so they both respond. > > > > *George J Molnar, KF2T* > FM19ma - Maryland, USA > > > > > > > > On Jan 20, 2023, at 3:56 PM, Jon Anhold via wsjt-devel < > wsjt-devel@lists.sourceforge.net> wrote: > > I was just on 20m trying to work W1AW/7, and W1AW/0 answered me, twice - > is this a known issue with longer/hashed callsigns? > > > > 73 de KM8V Jon > ___ > 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 > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib errors please for RC4 #hamlib
Hi Michael -- I have only so far seen warnings about dropped audio samples as shown below. I guess these have nothing in particular to do with Hamlib, but if you want more details, please let me know. 73, Paul K6PO [SYSLOG][2022-09-15 04:46:35.661153][00:00:00.000650][info] Log Start [SYSLOG][2022-09-15 04:46:35.661153][00:00:00.000719][info] WSJT-X - ForEW1 v2.6.0-rc4 c35798 by K1JT et al. - Program startup [SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013098][info] locale: language: English script: Latin country: United States ui-languages: en-US [SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013300][info] Loaded base translation file from :/Translations based on language en [SYSLOG][2022-09-15 04:46:35.676774][00:00:00.013336][info] Loaded translation file from :/Translations based on language en [SYSLOG][2022-09-15 04:46:35.723639][00:00:00.061776][info] shmem size: 48275456 [RIGCTRL][2022-09-15 04:46:35.754882][00:00:00.088692][info] Hamlib version: Hamlib 4.5~git Sun Sep 04 16:38:41 2022 + SHA=6c746c [SYSLOG][2022-09-15 04:46:59.410039][00:00:23.736465][warning] Detected dropped audio source samples: 2304 (0.048 S) [SYSLOG][2022-09-15 04:50:29.415028][00:03:53.740578][warning] Detected dropped audio source samples: 624 (0.013 S) [SYSLOG][2022-09-15 04:52:59.388463][00:06:23.713997][warning] Detected dropped audio source samples: 576 (0.012 S) [SYSLOG][2022-09-15 04:55:29.390469][00:08:53.716504][warning] Detected dropped audio source samples: 672 (0.014 S) [SYSLOG][2022-09-15 04:55:59.380954][00:09:23.706202][warning] Detected dropped audio source samples: 528 (0.011 S) ... On Wed, Sep 14, 2022 at 3:13 PM Black Michael via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > If everyone running RC4 would please check their wsjtx_syslog.log file and > see if there are any hamlib errors I would appreciate it. If > errors/warning are seen please send the log to me > > Getting ready to release Hamlib 4.5 and would like to ensure all is > working well. > > For Windows > C:\Users\[username]\AppData\Local\WSJT-X\wsjtx_syslog.dat > For Linux > /home/[username]\.local\share\WSJT-X\wsjtx_syslog.dat > > And RC4 version is not available for MacOS so no testing for Macs is > needed. > > Mike W9MDB > > > > ___ > 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
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
[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
