Re: [Discuss-gnuradio] RTP block / Opus vocoder

[Albin Stigö]

Hi Michelle,

Well my need for RTP/Opus is because of a Raspberry Pi FPGA based
shortwave transceiver for remote ham radio I'm building together with
Daniel, sm6vfz.

Today I sat down and wrote an RTP/Opus sink block and I have to say
it's working really well. I'm using libopus and jrtplib. My original
plan was to create two blocks: an Opus vocoder and and an RTP block
but after a while I found that that didn't make a lot of sense. RTP is
not designed to be a standalone protocol and is very application
specific. So in the end I wrote a combined block. It's probably not
more than 100 lines of C++ more than the boilerplate. Of course I will
have to add a bit more to make it fully configurable. I also haven't
written the xml for grc yet.

I will of course open source my work when I'm a bit further...

Next on my list is to add clock drift compensation on the alsasink.


--Albin SM6WJM

On Thu, May 10, 2018 at 4:54 PM, Michelle Thompson
<address@hidden> wrote:
> Hi Albin,
>
> We have a similar interest in getting RTP functionality in GNU Radio.
>
> Phil Karn recently wrote and published an SDR package for Phase 4 Ground
> that includes RTP multicast functionality. We have been talking about
> getting this functionality into GNU Radio. Another person interested in
> seeing this happen is David Rowetel from FreeDV. He and Phil have started
> talking about this.
>
> Ron and Marcus are of course correct in that RTP streams are already handled
> pretty well in GNU Radio. No, we do not want to reinvent the wheel.
>
> We would like to combine Opus/CODEC2 and RTP multicast to have stereo field
> audio. The sources of the audio appear at different points in the stereo
> field, so that a roundtable conversation feels more like a roundtable, or so
> that two streams from two different SDRs are distinct.
>
> Everyone is welcome to comment and contribute. The repository with the RTP
> multicast code from Phil Karn is here:
> https://github.com/phase4ground/ka9q-sdr
>
> If it can be done without a new block, then great. If there is value in
> handling bookkeeping, or functions in RTP multicast that would be much
> easier or much more useful in flowgraphs with a new block, then that's what
> we want to do. I have advice that it would be useful to get it into blocks.
> We want to do the right thing and we want comment and critique.
>
> Phase 4 Ground will have a "block party" at GNU Radio Conference 2018. The
> overall goal of Phase 4 Ground is to get DVB-S2 and DVB-S2X receive in GNU
> Radio. We have a dedicated room/lab for the week of the conference and will
> bring as much test equipment as we can fit into a minivan. Several
> satellite/modem/DVB docents have signed up and we're working on swag! If you
> have interest or expertise in any area of DVB-S2 receiver design, then we
> enthusiastically welcome you. We have a Slack and a mailing list.
> https://lists.openresearch.institute/
>
> One of the hard parts of the receiver is the LDPC FEC decode. We have one
> working implementation from Charles Brain, written for a GPU. It needs some
> work to get adaptive coding and modulation (we want ACM) working due to the
> architectural choices. It's a big achievement and it puts success more
> within reach. There are other hard parts in this receiver, but LDPC is
> challenging work. Having an open source version is a big step forward.
>
> Aside from ACM, we want to use generic stream encapsulation or GSE, which
> replaces the MPEG transport layer with a protocol that supports, well, you
> guessed it, generic data. This makes the downlink much more useful as a
> multiple access amateur radio system, which is where we're trying to go with
> all this work. Several of us have contributed GSE work that can be found in
> Wireshark and in GNU Radio, so working with GSE streams can be easier.
>
> -Michelle W5NYV
>
> "Potestatem obscuri lateris nescis."
>
>
> On Wed, May 9, 2018 at 9:54 AM, Albin Stigö <address@hidden> wrote:
>>
>> I'm looking specifically to improve the audio streaming of the GQRX
>> program which is based on gnuradio so it needs to be a block. I'll
>> experiment and see if I can come up with something useful.
>>
>> Thanks for all the suggestions though!
>>
>>
>> Albin
>>
>>
>> On Wed, May 9, 2018, 18:30 Müller, Marcus (CEL) <address@hidden> wrote:
>>>
>>> Well, I think you and Ron basically recommend the same functionality,
>>> but Ron is hesitant to reinvent the wheel:
>>>
>>> For local transport, UDP between your flowgraph and VLC works just
>>> fine. Also fine would be simply using a named pipe (FIFO, as in `man
>>> mkfifo`, if you're on something vaguely resembling UNIX) and a simple
>>> file sink (or source).
>>>
>>> Then, use VLC to receive those UDP packets containing raw samples, and
>>> encode them with Opus, and encapsulate them with RTP. (In the opposite
>>> direction, use VLC to receive an RTP stream, decompress the audio to
>>> raw audio samples, and send them via UDP to your flow graph)
>>>
>>> That would alleviate the need to have all this in a block, and test it
>>> yourself.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Wed, 2018-05-09 at 12:30 +0200, Albin Stigö wrote:
>>> > >  RTP is encapsulated in UDP. If you send an RTP stream to the GNU
>>> > > Radio UDP block, you will get an RTP stream.
>>> >
>>> > Exactly. But do you know if there already is a project to handle RTP
>>> > bookkeeping..? Otherwise I will start one. RTP is very application 
>>> > specific
>>> > but I'm looking to implement raw audio and opus. I'll try to make it 
>>> > modular
>>> > so that others can be built on top.
>>> >
>>> > --Albin
>>> >
>>> >
>>> > On Wed, May 9, 2018, 10:38 Ron Economos <address@hidden> wrote:
>>> > > RTP is encapsulated in UDP. If you send an RTP stream to the GNU
>>> > > Radio
>>> > > UDP block, you will get an RTP stream.
>>> > >
>>> > > VLC is just a suggestion. It can send RTP containing Opus.
>>> > >
>>> > > Ron
>>> > >
>>> > > On 05/09/2018 01:10 AM, Albin Stigö wrote:
>>> > > > Well RTP provides important functionality when streaming over the
>>> > > > internet. Especially time stamping and sequence numbering which
>>> > > > allows
>>> > > > to reassemble out of order data (UDP provides no such guarantee)
>>> > > > and
>>> > > > adjustment for clock drift which, among other things, allows you to
>>> > > > keep the receiver buffer smaller for "real time" tuning.
>>> > > >
>>> > > > RTP also provides a "telemetry" channel over RTCP for network
>>> > > > statistics.
>>> > > >
>>> > > > Not sure why you assume I will use VLC?
>>> > > >
>>> > > > Of course if you are just streaming over a LAN raw UDP might be ok
>>> > > > since the risk of out of order packets is essentially zero.
>>> > > >
>>> > > >
>>> > > > --Albin
>>> > > >
>>> > > >
>>> > > > On Wed, May 9, 2018 at 9:35 AM, Ron Economos <address@hidden>
>>> > > > wrote:
>>> > > >> RTP runs over UDP. Why would you need a block? Just let VLC do all
>>> > > >> the dirty
>>> > > >> work.
>>> > > >>
>>> > > >> Ron
>>> > > >>
>>> > > >>
>>> > > >> On 05/08/2018 11:59 PM, Albin Stigö wrote:
>>> > > >>> Hi all,
>>> > > >>>
>>> > > >>> Is there an RTP (real time protocol) streaming block? I know
>>> > > >>> about the
>>> > > >>> UDP block but I want RTP/RTCP.
>>> > > >>>
>>> > > >>> If not I will start writing one... Just don't want to start a new
>>> > > >>> project if there already is one.
>>> > > >>>
>>> > > >>> Also, what happened to Opus in the gr-vocoder? Thinking about
>>> > > >>> writing
>>> > > >>> an opus block as well.
>>> > > >>>
>>> > > >>> The goal is streaming opus encoding audio from gnuradio from
>>> > > >>> remote
>>> > > >>> locations.
>>> > > >>>
>>> > > >>>
>>> > > >>> --Albin
>>> > > >>>
>>> > > >> _______________________________________________
>>> > > >> Discuss-gnuradio mailing list
>>> > > >> address@hidden
>>> > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > > > _______________________________________________
>>> > > > Discuss-gnuradio mailing list
>>> > > > address@hidden
>>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > Discuss-gnuradio mailing list
>>> > > address@hidden
>>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>> >
>>> > _______________________________________________
>>> > Discuss-gnuradio mailing list
>>> > address@hidden
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>