Re: [wsjt-devel] Audio input from RTP stream?

2018-03-28 Thread Joe Taylor 

Hi Alex,

These sound like good ideas to me.  A mechanism for sending I/Q data 
into WSJT-X has been on our back-burner "To Do" list for some time.  But 
as you can probably guess, I'm only superficially familiar with the 
protocols you're considering.  Bill will probably have a more useful 
response for you.

-- Joe, K1JT

On 3/28/2018 10:34 AM, Alex, VE3NEA wrote:

Hello developers,

I am looking into supporting the RTP+RTCP protocol in CW Skimmer, and I 
want to do this in a way compatible with other software, including 
WSJTX. RTP seems to be the best way of exchanging the I/Q data between 
the programs, but it needs to be complemented with another protocol for 
reading and setting the radio's parameters. I was thinking about using 
NDJSON over TCP for that (https://github.com/ndjson/ndjson-spec), the 
solution that worked well in my GRITTY project 
(http://dxatlas.com/Gritty/). However, Hubert, HB9JND has drawn my 
attention to the new TCI protocol (https://github.com/maksimus1210/TCI) 
that seems to have all required radio control commands, but sends I/Q 
data via TCP. Do you think it would make sense to combine RTP+RTCP (for 
data) with TCI (for commands)? Would you be interested in supporting 
this combination in WSJTX? Are there any good alternatives to this 
solution?


73 Alex VE3NEA


--
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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-28 Thread Alex, VE3NEA 

Hello developers,

I am looking into supporting the RTP+RTCP protocol in CW Skimmer, and I want to do this in a way compatible with other software, 
including WSJTX. RTP seems to be the best way of exchanging the I/Q data between the programs, but it needs to be complemented 
with another protocol for reading and setting the radio's parameters. I was thinking about using NDJSON over TCP for that 
(https://github.com/ndjson/ndjson-spec), the solution that worked well in my GRITTY project (http://dxatlas.com/Gritty/). 
However, Hubert, HB9JND has drawn my attention to the new TCI protocol (https://github.com/maksimus1210/TCI) that seems to have 
all required radio control commands, but sends I/Q data via TCP. Do you think it would make sense to combine RTP+RTCP (for data) 
with TCI (for commands)? Would you be interested in supporting this combination in WSJTX? Are there any good alternatives to 
this solution?


73 Alex VE3NEA

--
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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-08 Thread Игорь Ч via wsjt-devel 
Hello Phil,
.
>Igor, the whole point of playing out silence is to maintain
>synchronization. If, for example, the sampling rate is 48 kHz and your
>RTP packets each contain 240 samples (5 milliseconds), then I would
>replace a single missing packet with 240 samples of binary zeroes. Your
>signal blanks for 5 ms, but synchronization is maintained when it
>reappears. Most of the slower JT schemes wouldn't even notice.
.
We have been using correlation function to get in sync with the signal 
we are going to demodulate, where evaluated delta time (DT) of candidate
signal shall match to the transmitted signal. Since we have been using 
FSK modulation high accuracy of derived DT will let us to get the best SNR
of demodulated signal and will decrease number of errors prior passing
demodulated codeword to the decoder.
There are two level steps introduced in time domain if lost frames were replaced
with zero values, this steps in level can be as high as 90 dB and always making
horizontal spike line in the frequency domain, energy of this line depends on
the step value.
For instance, let's say we have got two signals being received in the same
interval, where power of one signal is 40dB higher than other one's.
We are getting one..two more wrong tones at demodulation for weaker signal
for each silence insertion, these artificial noise 'tones' shifting peak of the
correlation function bringing erroneous DT result.
There are several options to manage this error: we can try to make smooth
level transition in time domain between point A and point B where instead
of the silence. Other option is to try reconstruct time domain signal between
these points using previous/post frames as we know where there is the gap.
.
73 Igor UA3DJY


--
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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-07 Thread Phil Karn 
On 3/6/18 08:05, Bill Somerville wrote:

> 
> 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?

Bill,

I'm finally reading through the RTCP spec (have only implemented RTP so
far) and I see it already solves your exact problem. Every participant
in a multicast group periodically multicasts reports to the group. Every
RTCP sender report includes a 32-bit RTP timestamp and a corresponding
NTP (Network Time Protocol) timestamp. This lets every receiver derive
absolute clock time (to the sender's accuracy) for any received sample
in the RTP stream.

The 64-bit NTP timestamp is divided into two 32-bit parts: an integer
count of seconds since January 1, 1900 (at 00:00:00 UT, presumably) and
a 32-bit count of fractional seconds.

As much as I dislike NTP's use of universal time, which introduces the
many headaches of leap seconds, and the fact that this timestamp will
roll over in 2036, I will probably switch to using it to timestamp my
I/Q samples to avoid inflicting yet another "standard" on the world.

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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-07 Thread Phil Karn 
On 3/7/18 01:33, Игорь Ч via wsjt-devel wrote:

> Playing out silence in place of the lost packets is not a good idea:
> it will distrurb sychronization and will bring wrong Delta Time values 
> to the weak signals at demodulation. I would suggest usage of some 
> averaging instead of the silence.
> .
> 73 Igor UA3DJY

Igor, the whole point of playing out silence is to maintain
synchronization. If, for example, the sampling rate is 48 kHz and your
RTP packets each contain 240 samples (5 milliseconds), then I would
replace a single missing packet with 240 samples of binary zeroes. Your
signal blanks for 5 ms, but synchronization is maintained when it
reappears. Most of the slower JT schemes wouldn't even notice.

My experience is that local wired Ethernet networks are extremely
reliable unless overloaded. Lost packets are very rare and reordered or
corrupted packets are almost unheard of unless something is *very* broken.

WiFi 802.11 is a different and somewhat complex story. Delays are much
more variable due to contention and other physical layer problems.
Packet loss depends on whether they're sent as physical multicasts or
unicasts. Physical unicasts are acknowledged at the physical layer so
they can might arrive late (i.e., with a lot of delay variance) but are
usually not dropped.

Multicast is different. A physical layer 802.11 multicast is sent at a
very low "base rate" to maximize reception probability at every user
station. They're not acknowledged. Not only can that lose packets, the
low base rate can make the channel almost unusable if there's a lot of
multicast traffic (like one of my I/Q streams).

Some access points (like my Engenius 600) have a "multicast to unicast
conversion" feature so that a multicast frame arriving on the Ethernet
is sent as a series of unicast frames, one for each mobile station that
has subscribed to the multicast group. Then each unicast can be sent at
whatever speed that link can bear, and they're individually acknowledged
for reliability. This is almost always vastly faster than a physical
multicast.

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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-07 Thread Игорь Ч via wsjt-devel 
Hello Phil,
>I implemented RTP in about a page of C code, not counting all of the
>UNIX/Linux system calls needed to set up multicast sockets. That's
>actually the only hard part. With RTP I just check that the next packet
>is in sequence, drop any old duplicates, and play out silence in place
>of lost packets to maintain timing, which is much more important for
>digital demodulators than for human speech.
.
Playing out silence in place of the lost packets is not a good idea:
it will distrurb sychronization and will bring wrong Delta Time values 
to the weak signals at demodulation. I would suggest usage of some 
averaging instead of the silence.
.
73 Igor UA3DJY



--
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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-07 Thread Phil Karn 
To Bill (and Joe),

It just occurred to me that I could multicast my receiver output to you
in the frequency domain. UDP already provides the necessary framing. We
just define that as a new RTP "codec type".

I use fast convolution with overlap-and-save for filtering, so as long
as I tell you the parameters (i.e, FFT block size and the overlap
amount) I could just give you the frequency domain signal before I'd
ordinarily perform the IFFT. This would save me the IFFT (though I'd
probably do it anyway just so I could listen). With the right blocksize,
it might also save you an FFT.

To be honest, at that point there wouldn't be much left for my receiver
to do. Or you could just read my raw SDR I/Q streams directly...

We could also reduce the bandwidth by just truncating the frequency
information, though I'd have to apply a low pass decimation filter to
avoid aliasing. I use Kaiser windowing for pretty much everything; I
really like its tuning knob to trade transition sharpness against
stopband sidelobes. (I also worked with Jim Kaiser at Bellcore way back
in the 1980s.)

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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-07 Thread Phil Karn 
On 3/6/18 08:05, Bill Somerville wrote:

> 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.

This is great news!

> 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?

RTP is really very simple. It's documented in RFC-3550 ("A Transport
Protocol for Real-Time Applications"). It also defines RTCP

I implemented RTP in about a page of C code, not counting all of the
UNIX/Linux system calls needed to set up multicast sockets. That's
actually the only hard part. With RTP I just check that the next packet
is in sequence, drop any old duplicates, and play out silence in place
of lost packets to maintain timing, which is much more important for
digital demodulators than for human speech.

Where RTP can get tricky is in managing timing jitter. This isn't a
problem on most LANs unless they're severely overloaded. Over a longer
path the problem is always picking the right size for the playout
buffer, trading off latency against the risk of dropping packets that
arrive just a little too late. This is only a problem for interactive
voice; it's a non-problem for a program like WSJT that processes signals
in large chunks. For example, with WSPR your "playout buffer" could be
the entire two minutes long; just drop each RTP packet into the right
place in the buffer when it arrives and start the decoder on the even
minute as usual.

I haven't implemented RTCP yet but I will soon. The receiver statistics
aren't very useful on a LAN, but RTCP looks like the best way for a
multicast sender to tell who's listening so it can not bother sending
when there isn't anybody. With IGMP snooping the multicast streams don't
really go anywhere when nobody is listening, but the sending computer
could still save some CPU cycles.

> 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?

RTP also provides a 32-bit relative timestamp. Its exact meaning depends
on the codec; in general it's supposed to count audio samples at the
encoder input or decoder output (or frames for video). For 48 kHz PCM
(any number of channels and any number of bits per sample) the timestamp
increments every 1/48000 sec of real time. So if a PCM packet contains
960 samples (20 ms @ 48 kHz) the RTP timestamp increases 960 with each
packet. It's the same even with compressed signals; for example, if you
use Opus with 20 ms frames the RTP timestamp still increases by 960 for
each packet even though the actual number of (compressed) bytes in the
packet varies (and is considerably less than 960).

This is a *relative* timestamp unrelated to clock time. I've thought a
lot about the absolute timestamp problem as I also have it with the
AFSK/FM demod, HDLC receiver and APRS data extractor I wrote to process
my receiver output so our satellite antennas can automatically track the
high altitude balloons we fly at the high school ham club.

For I/Q streams I insert my own metadata header between RTP and the data
that carries the receiver LO frequency, sample rate and analog gain
settings. I just recently added absolute clock time represented as a
64-bit integer count of nanoseconds since the GPS epoch of 6 January
1980 00:00:00 UTC (don't get me started about leap seconds).

But doing that on receiver audio output would be incompatible with audio
players like VLC that can play multicast 16-bit linear PCM. Listening
directly to a raw I/Q stream doesn't seem very interesting, so there I
don't mind the incompatibility.

So the clock time problem is currently unsolved on the receiver output,
but I'm thinking of periodically sending the clock time in a separate
metadata packet. It would give the wall clock time (or the original wall
clock time for an I/Q playback) that corresponds to a particular RTP
timestamp. The sample rate ought to be accurate enough to interpolate
between those metadata updates. Remember I already fill in any missing
I/Q frames with zeroes to maintain synchronization.

IMHO, many network audio streaming schemes have huge latency because
they use TCP, which was never designed for real-time traffic. That's
what RTP/UDP is for.

I work to keep the delays in my own SDR as small as possible.

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-06 Thread Phil Karn 
On 3/6/18 06:48, Joe Taylor wrote:
> 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.

Great. I hadn't thought of that, but you're right. Not only would this
free up your computer's sound system for other uses, it would avoid all
of the usual computer audio system limitations.

It would be very easy to give you a "stereo" (complex I/Q) audio stream.
I did use a complex-to-real IFFT in my fast correlator for SSB mode but
I simplified the program by just using complex-to-complex for everything
and throwing the imaginary part away in SSB/CW mode. That'd be an easy
way to double bandwidth without increasing the sample rate.

If you use complex signals internally, giving you complex audio could
let you avoid the Hilbert transform (or equivalent) necessary to
regenerate the analytic signal from a purely real one (not that that's
particularly difficult).

Zero frequency isn't a problem in a purely digital format, but neither
have I had any significant analog 0 Hz problems with my AMSAT UK Funcube
SDR dongle. There's a DC offset but it's easy to remove. This leaves a
small mound of phase noise maybe 1-2 kHz wide, probably from reciprocal
mixing. I only notice it with the antenna disconnected and normally it's
completely buried. In any event, I do my own frequency translations so
DC from the front end isn't necessarily DC in my output signal.

> 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.

Yeah, why not? If your SDR front end can cover an entire band, and if
you have enough CPU cycles, you could easily extract everything in an
entire band. One program would look for JT65, a completely independent
program looks for WSPR, a third one for Winlink or Domino or PSK31 or
whatever, and so on. These independent programs can run on the same
computer or on a collection of computers, all processing a single input
stream.

> 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.

I'll look at it, thanks.

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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-06 Thread Bill Somerville 

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.


73
Bill
G4WJS.


--
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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-06 Thread Michael Besemer 
FT8 is already encroaching on the PSK subbands (or in the case of 17 meters 
right on top of the PSK subband) and probably others too.  PLEASE be a good 
neighbor and don't do anything to make it worse.  Everyone needs to share a 
very limited resource.  Just because FT8 is popular does not provide license to 
rain on everyone else's parade.

Mike
WM4B
On Mar 6, 2018 9:49 AM, Joe Taylor  wrote:
>
> 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 
--
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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-06 Thread Joe Taylor 

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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-06 Thread Phil Karn 
On 3/5/18 23:24, Borja Marcos wrote:

> That would be really awesome, defining some standard “audio bus” for 
> radio applications.

Well, there's really not much to define since the work has already been
done for us by the IETF (Internet Engineering Task Force). Multicasting
is heavily used on LANs, mainly for resource discovery (especially by
Apple's Bonjour, which is also an IETF standard).

But IMHO IP multicasting hasn't lived up to its full potential, mainly
because few ISPs support it natively so you have to set up ad-hoc
tunnels. It's the basis of AT's U-verse service, and I'm looking hard
at using it for "smart" wide area roundtables and repeater links in ham
radio, but that's getting off topic.

RTP can be used with any audio format (or video, for that matter). I use
Opus (a fairly new and very nice lossy audio compression format) for
stuff I'm going to listen to by ear, but I still use PCM for anything
I'm going to feed to a demodulator program. They can easily coexist in
the same network. E.g., I wrote a simple server task that 'bridges'
multicast PCM to Opus to make it easy to listen remotely to the output
of a receiver module that produces only PCM.

> Making it multi platform and multi tooklit can be 
> tricky, though. WSJT-X is based on Qt audio. But, what about other apps?

The whole idea is to completely AVOID the audio subsystem on the host
computer running WSJT-X (or any other demod program, for that matter).
So there's no need for audio patching utilities like Jack or
Soundflower. A program like WSJT-X simply reads and processes (and/or
writes) multicast streams that just happen to contain digital audio. But
they're handled as ordinary data packets by the operating system.

But if I want to monitor the audio input to (or output from) a program
like WSJT-X, I can simply fire up a completely independent "multicast
monitor" program that joins the appropriate multicast group and streams
the audio to the local sound system. Otherwise I could listen to music,
watch a video, whatever, while WSJT-X quietly runs in its own window.

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

Re: [wsjt-devel] Audio input from RTP stream?

2018-03-05 Thread Borja Marcos 


> On 6 Mar 2018, at 07:29, Phil Karn  wrote:
> 
> How hard would it be for WJST to accept receive audio from a RTP (Real
> Time Protocol) multicast network stream?
> 
> 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.

Several years ago I did something of that sort using Quicktime Broadcaster and
Digital Performer. I was showing a friend how to have someone far away listen to
my mixing bus and it worked very well.

I used Jack OS X but I’m not sure wether it still works on Mac OS X It wasn’t
so bad in software compatibility (if I remember well we were keeping a voice
chat with iChat). Of course you had to be careful and make sure that stuff
like system sounds were routed to a different output but other than that it
worked.

https://en.wikipedia.org/wiki/JACK_Audio_Connection_Kit

It was several years ago but I think I remember that a couple of years
later I tried Soundflower and I had some problems with it. But it could be 
just the changes Apple had been making in Core Audio. 

In my case I was streaming stereo 24 bit @44.1 KHz audio and
meanwhile I was running Digital Performer mixing a multi track recording
(no more than eight tracks, that’s an advantage of jazz!). The machine
was a Power Mac G5 and I ran everything together (Digital Performer,
Quicktime Broadcaster and Jack OS X).

> 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.

That would be really awesome, defining some standard “audio bus” for 
radio applications. Making it multi platform and multi tooklit can be 
tricky, though. WSJT-X is based on Qt audio. But, what about other apps?

Maybe Jack (i see there is a Jack2 version and it supports Windows as well)
could work?

https://github.com/jackaudio/jackaudio.github.com

Sorry about being a bit vague, I haven’t looked at this for a long time!




Borja - EA2EKH



--
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

[wsjt-devel] Audio input from RTP stream?

2018-03-05 Thread Phil Karn 
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