Difference between revisions of "Bidirectional PAD communication protocol"

From OpenDigitalRadio
Jump to navigationJump to search
(Replace version by type)
 
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
 

Latest revision as of 09:21, 23 September 2020

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