On 03/05/2014 20:11, Joe Taylor wrote:
> Hi all,
Hi Joe,
>
> I'm happy to report that I haven't heard a Tx audio glitch from WSJT-X
> for some time. Bill probably knows exactly when (and why, at least
> approximately) this stopped happening. As far as I can see, the Tx
> audio is now as rock-soli
I can confirm that that change resolved TX audio issues I had with
WSJT-X in Linux (Arch). Works perfectly well now. WSPR 4.0 is also
running nicely natively, hadn't tried it before yesterday, but was using
WSPR 2.12 under Wine prior. My hope is that WSPR-X will also benefit
from a similar a
Hi all,
I'm happy to report that I haven't heard a Tx audio glitch from WSJT-X
for some time. Bill probably knows exactly when (and why, at least
approximately) this stopped happening. As far as I can see, the Tx
audio is now as rock-solid as it is in WSJT and WSPR -- and as it was in
WSJT-X
Hi John,
I just finished working on the Samplerate, Portaudio adn FFTW
AC_CHECK_HEADERS, and also included proper -I and -L paths, so of if
configure can't find the headers, AC_MESSGE then [Break], so this whole
configure with --with-portaudio .. .. is overtired now. We really need
to add prop
Hi Greg,
Noted your changes in Makefile.in. One other thing I have noticed for both
WSJT and WSPR compilations is the final part of the make:
${MV} w.cpython-3*.so WsprMod/w.soand
${MV} Audio.cpython-32mu.so WsjtMod/Audio.so
on the Mac the cpython-3* and cpython-32mu do not exist. It'
Hi John,
On 05/03/2014 03:01 AM, John Nelson wrote:
> Hi Greg,
>
>> Are you the one maintaining WSPR Makefile.10.6 in the source tree?
> Yes. A separate Makefile was needed when running on 10.6 with python
> 2.5/2.7. In the last few days I have upgraded to python 3 which is now a
> prerequis
Hi Greg,
> Are you the one maintaining WSPR Makefile.10.6 in the source tree?
Yes. A separate Makefile was needed when running on 10.6 with python 2.5/2.7.
In the last few days I have upgraded to python 3 which is now a prerequisite
and I notice that a number of issues have fallen away for