Bidirectional PAD communication protocol

From OpenDigitalRadio
Revision as of 13:07, 6 February 2017 by Hb9egm (talk | contribs) (Created page with "The current ODR-PadEnc to ODR-AudioEnc communication is done through a nonblocking FIFO. The proposal is to replace it by a UDP-based request/reply protocol. For eve...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

The current ODR-PadEnc to ODR-AudioEnc communication is done through a nonblocking FIFO.

The proposal is to replace it by a UDP-based request/reply protocol.

For every audio frame, the ODR-AudioEnc checks if a block of PAD data is available by doing a nonblocking recv() on the UDP socket. If yes, it inserts it into the audio frame; if not, the audio frame will not contain PAD. In any case, it sends a request to ODR-PadEnc for new data:

   UDP PAD Request version 1 - message format
   | version (1 byte) |
   | 0x1              |

ODR-PadEnc prepares the PAD block and answers with a UDP reply message:

   UDP PAD Reply version 1 - message format
   | version (1 byte) | PAD data (N bytes) |
   | 0x1              |       <PAD>        |

TODO:

  * Define the order of bytes for the PAD data
  * Endianness of multi-byte values (none yet)
  * Do we want to add a type field with a different value for request and reply?