ghost
commented
4 years ago I'd probably prefer a packet_type indicator.
High latency is horrible, and makes radio use unpleasant, not to mention un-intuitive. It makes doubling much more likely, conversations have to go slower, etc. We'll already have 100+ ms latency with networking, so now I'll hear the end of the transmission and more than a second may go by before anyone hears me key up. That's without dealing with interlinked repeaters, which will add more latency. Other networks have high latency, so it may be "acceptable", but if we can do better at every stage, i think we should - which would mean not adding more to the RF layer unless we absolutely have to.
That's a good point though - the important parts of the LICH are the destination and stream type - and if it's encrypted, the nonce. I don't know if it's a good idea to decode audio before having the full LICH - but if we don't need the full LICH to decode audio, I'd say that gives a good reason to re-examine all the parts of the LICH for their purpose.
In general, I'd say fully rearranging things, or even going 1600bps C2 all the time to fit a packet type indicator would be preferable to having high latency. OR - why send LICH chunks that have to be reassembled? That's for handling late joiners, is there anyway we can drop LICH chunks and have LICH sent periodically for that use case?
The reason to have initial LICH frame is to provide an early info on the ongoing transmission. Do we need that? One of the pros is that it decreases the end-to-end delay. The problem is that we are going to need some way of telling that the frame we have received is the initial LICH. One of the methods is to use a different syncword for that frame.
1) At the receiver side, we have to buffer audio anyway. Theoretical end-to-end delay for our present spec is 40ms (that's the frame length) plus maximum decoding time, let it be 10ms. I assume that the decoding time may vary from frame to frame, depending on the speech signal. 2) We are not implementing a full duplex system. A lag of at most 250ms* seems OK for half duplex. 3) What is the chance of actually receiving the initial LICH frame? 4) After receiving a full Superframe, receiving parties can decide to start decoding or ignore the transmission. This is also possible as early as after 2 frames are received (full DST_ID is available by then).
*even 90ms if getting 2 LICH chunks is enough to decide