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 <mountain.miche...@gmail.com> 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ö <albin.st...@gmail.com> 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) <muel...@kit.edu> 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 <w...@comcast.net> 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 <w...@comcast.net> >>> > > > 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 >>> > > >> Discuss-gnuradio@gnu.org >>> > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> > > > _______________________________________________ >>> > > > Discuss-gnuradio mailing list >>> > > > Discuss-gnuradio@gnu.org >>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> > > >>> > > >>> > > _______________________________________________ >>> > > Discuss-gnuradio mailing list >>> > > Discuss-gnuradio@gnu.org >>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> > >>> > _______________________________________________ >>> > Discuss-gnuradio mailing list >>> > Discuss-gnuradio@gnu.org >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio