Hi Phil,
Your idea sounds reasonable. It might be a good way to enable wideband
receiving -- that is, reception (of FT8, say) over a passband
significantly greater than 5 kHz, currently the practical limit. The
popularity of FT8 on the HF bands implies that wider sub-bands would be
very desirable.
With MAP65 we already have significant experience with wideband
reception of JT65 EME signals. It works very well, and is a big
advantage. It can be set up to decode all JT65 signals over a 90 kHz range.
When receiving WSJT-X currently acquires audio data via the C++ class
defined in Detector.cpp. Your best contact person is probably Bill,
Somerville, G4WJS. Fair warning: Bill is in the middle of some major
contract work, so his available time is limited.
-- 73, Joe, K1JT
On 3/6/2018 1:29 AM, Phil Karn wrote:
How hard would it be for WJST to accept receive audio from a RTP (Real
Time Protocol) multicast network stream?
RTP is *the* standard for voice over IP (VoIP). It runs over UDP/IP,
usually as unicast IPv4 but also as multicast IPv4 or IPv6. It's just a
streaming protocol that identifies and sequence numbers packets. It can
carry any codec you want.
I've been writing my own SDR from scratch over the past year or so. A
core design feature is the use of IP multicasting for all inter-module
communications, e.g., I/Q sample streams, uncompressed PCM audio,
Opus-compressed audio, decoded digital data frames, hardware status,
metadata, etc.
I've found this to be remarkably versatile and practical. Any number of
receivers can listen to a multicast stream without any prior
arrangement. The various modules can be on the same system, on different
systems on the same LAN, or systems in different locations connected by
a multicast-capable IP network. Modules can be individually stopped and
restarted without killing others (though some real-time data will of
course be lost.)
My receiver outputs uncompressed audio as a standard RTP/UDP/IP
multicast stream containing mono or stereo 16-bit linear PCM audio at 48
kHz. To now get this into WSJT on OSX, I run my RTP receiver/player
program, intercept the OS X audio with Soundflower, and then tell WSJT
to take its input from Soundflower.
This sort of works, but it causes problems. You have to be careful to
keep system sounds out of Soundflower, and you can't run any unrelated
sound applications.
It would be great if WSJT could natively process an incoming RTP audio
stream without touching the local machine's audio subsystem. It would
not have to echo to the system audio output; if want to monitor it I can
simply run an instance of my RTP audio player that will join the same
multicast stream and WSJT doesn't need to know.
As a follow-on project, it would also be nice to give WSJT the option of
generating a RTP stream with transmit PCM audio.
I'm willing to do the work myself, but I'd like to know if anybody else
is already working on something like this, or if anyone has advice for
how to minimize my changes to the WSJT program structure. (I've not
looked at the source yet.)
73, Phil
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
