On 06/03/2018 06:29, Phil Karn wrote:
How hard would it be for WJST to accept receive audio from a RTP (Real
Time Protocol) multicast network stream?

Hi Phil,

not very hard at all. The audio in WSJT-X is via a Qt I/O Device abstraction and making a UDP server that joins a multicast group to receive and send audio would only require a thin layer to manage datagram reception and transmission converting into/out of a stream in/out of respective QIODevice sub-classes is about the whole requirement. The Modulator and Detector classes in WSJT-X are pretty much agnostic about which QIODevice derivative they talk to for PCM sample streams.

Can you point me to somewhere I can get information about gathering RTP datagrams and combining as a continuous stream? Do I need to work with RTCP as well?

Our experience of users using the Elecraft remote kit using IP streaming is that latency and delay are a problem, this being because of our dependence on external wall clock synchronization. Can RTP provide absolute time-stamp information that we can leverage to capture UTC time sync relative to the source? Is there a recovery mechanism to "unbuffer" when delays accumulate?

I assume the RTP payload formats are usually compressed, can we use uncompressed PCM at 48000Hz 16-bit (actually 12000Hz 16-bit is all we require unless we go to wider bandwidths) and still expect timely delivery? If not, are we heading for a world of pain with proprietary codecs?

I have some experience as I used to work on a set top box application that streamed MPEG-4 over ADSL Internet, we used the Intel IPP libraries for codecs rendering to a Linux frame buffer and sending either web-camera or Ethernet based stand-alone camera streams.


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

Reply via email to