Difference between revisions of "Bidirectional PAD communication protocol"
From OpenDigitalRadio
Jump to navigationJump to search (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...") |
|||
| Line 17: | Line 17: | ||
TODO: | 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? | |
Revision as of 13:07, 6 February 2017
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?
