Bidirectional PAD communication protocol - Revision history

Hb9egm at 08:21, 23 September 2020

2020-09-23T08:21:22Z

Hb9egm: Replace version by type

2017-02-06T12:59:34Z

Replace version by type

Hb9egm at 12:07, 6 February 2017

2017-02-06T12:07:59Z

Hb9egm: 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..."

2017-02-06T12:07:46Z

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

New page

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?

← Older revision		Revision as of 08:21, 23 September 2020
Line 1:		Line 1:
−	The ~~current~~ [[ODR-PadEnc]] to [[ODR-AudioEnc]] ~~communication is~~ done ~~through~~ a nonblocking FIFO.	+	The communication between [[ODR-PadEnc]] and [[ODR-AudioEnc]] was done using a nonblocking FIFO until ODR-PadEnc v3, and was subsequently replaced by a unix domain datagram socket.

−	The ~~proposal is to replace it by a UDP-based request~~/~~reply protocol~~.	+	The implementations are in https://github.com/Opendigitalradio/ODR-PadEnc/blob/master/src/pad_interface.cpp and https://github.com/Opendigitalradio/ODR-AudioEnc/blob/master/src/PadInterface.cpp
−
−	~~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 - message format~~
−	~~\| type (1 byte) \|~~
−	~~\| 0x1 (request) \|~~
−
−	~~ODR-PadEnc prepares the PAD block~~ and ~~answers with a UDP reply message~~:
−
−	~~UDP PAD Reply - message format~~
−	~~\| type (1 byte) \| PAD data (N bytes) \|~~
−	~~\| 0x2 (reply) \| <PAD> \|~~
−
−	~~Future versions of the messages as well as new types of messages shall use different values for the type field~~.
−
−
−	~~Multi~~-~~byte values (none yet) use network endianness (i.e. big-endian)~~.
−
−	~~TODO:~~
−
−	* Define the order of bytes for the PAD data

@@ Line 5: / Line 5: @@
 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
+     UDP PAD Request - message format
-     | version (1 byte) |
+     | type (1 byte) |
-     | 0x1              |
+     | 0x1 (request) |
 ODR-PadEnc prepares the PAD block and answers with a UDP reply message:
-     UDP PAD Reply version 1 - message format
+     UDP PAD Reply - message format
-     | version (1 byte) | PAD data (N bytes) |
+     | type (1 byte) | PAD data (N bytes) |
-     | 0x1              |       <PAD>        |
+     | 0x2 (reply)   |       <PAD>        |
 TODO:
 * Define the order of bytes for the PAD data

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