| That’s what we did for Linux on my project, but it’s kind of a kludge. Better to have WSJT-X be able to handle audio IQ natively.
On the Mac I used netcat and the “Blackhole” virtual audio driver. I pointed WSJT-X at the virtual audio device.
73,
Kevin
Sent from my iPad On Feb 28, 2024, at 11:15, Thomas Reynolds via wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote:
In the Linux world you can use PulseAudio to transport soundcard audio from a remote RPi and radio over the net to a local desktop running WSJT-X. I do this. It works fine provided that the latency is not too large.
Splitting the UI and data processing code would mean a major rewrite of the project. It might be much easier to implement some
API, e.g. REST-based, for the functions that are currently performed via the UI. Then WSJT-X would run with its main window
minimized or hidden on the remote system, and the controlling app with UI would run in the shack.
73 Alex VE3NEA
On 2024-02-28 13:12, Rafael Pinto via wsjt-devel wrote:
> William,
>
> You got the architecture right. The point is not having to render images and treat UI events, thus having all processing power
> for mathematical computation. X Windows System and Wayland are memory and CPU hogs and in some cases those resources are at a
> premium...
>
> As I read the code, trying to figure out how WSTJ-X works, I notice how tightly coupled UI and data processing are. I understand
> it can be easier to show things on the GUI, but decoupling those could allow for some different UX (text-only, for example) or,
> as I suggested, some "smart" remoting.
>
> To be 100% honest, the distributed processing approach I proposed is just a thought experiment on how to decouple the many
> modules. Having each "module" on a different machine is usually how I think when I try to decouple complex stuff.
>
> I'll keep studying the code to try and figure out how it would be possible...
>
> 73
>
> Rafael
>
> On Wed, Feb 28, 2024 at 1:01 PM William Smith via wsjt-devel <wsjt-devel@lists.sourceforge.net
> <mailto:wsjt-devel@lists.sourceforge.net>> wrote:
>
> I get what you were trying to do, and it is not a perfect solution, but many people use VNC or some other kind of remote
> desktop protocol to remotely control the computer that is running WSJT.
>
> Yes, it would be much better to unload the GUI and the output video requirements from the poor Raspberry Pi and let that run
> on some machine that has a lot more available horsepower. However, as you are determining, that is a lot of work, and the
> remote desktop thing has the advantage of not requiring any coding at all from the WSJT team.
>
> 73, Willie N1JBJ
>
>
> > On Feb 28, 2024, at 7:11 AM, Rafael Pinto via wsjt-devel <wsjt-devel@lists.sourceforge.net
> <mailto:wsjt-devel@lists.sourceforge.net>> wrote:
> >
> >
> > Hello folks
> >
> > Sorry if this has already been discussed!
> >
> > I am Rafael, PU1OWL, and I was thinking if it would be possible to detach the GUI frontend from the
> modulation/audio/realtime backend of WSJT-X so we can make it a remote module
> >
> > The architecture I envision is having a remote processor (e.g., some bulky raspberry pi, a PicoITX i9 board...) dealing
> with the mathematical heavy lifting while not having to put CPU into presenting its GUI. The GUI could be remote, on a PC or
> another raspberry pi, or something even lighter... Or maybe even some audio sink board, forwarding to a hugely capable math
> processor, to a lightweight GUI...
> >
> > I started studying the source code, but I cannot find somewhere to split the code. Has it been tried before?
> >
> > 73 de PU1OWL
> >
> > Rafael Pinto
> > _______________________________________________
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel <https://lists.sourceforge.net/lists/listinfo/wsjt-devel>
>
>
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel <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
|
