When receiving via the Internet into a repeater the problem of how to handle network drop-outs occurs. The transport mechanism of choice for streaming is UDP which does not guarantee delivery, but delivers data in a timely manner. Perhaps more importantly, unlike TCP it will not stall waiting for a lost frame, it will just continue. From the users’ point of view it is probably better to have a small gap in the audio than to have it stop until the lost frame has been retried and received then continue. This delay could be considerable fraction of a second.
With D-Star which has frames that contain 20ms of audio, a lost frame is for the most part not a big deal. What is important is how to handle it. A few years ago I did some tests and determined that for gaps of 40ms or less, it is OK to repeat the last 20ms of audio to fill the time. It sometimes sounds a little odd, but not too bad. A gap longer than that is better served by silence as the repeated sound really starts to grate if held for too long. This approach has been is use for a number of years and seems to sound reasonable.
DMR uses blocks of 60ms of audio in each frame, made up of three times 20ms of audio. Therefore audio will be lost in multiples of 60ms which is an appreciable gap. So what to do about infilling the audio when a frame is lost?
There are three potential approaches: repeat the last 60ms as-is, or take the last 20ms of audio and repeat that, or simply insert silence. If we follow the D-Star method then the second option would be the way to go and then follow with the silence option if the gap is loner.
Recently the local Hytera DMR repeater was relaying a talk group and somewhere along the line, there was some network loss. In order to fill in the lost frames I think it repeated the last 60ms audio a few times and it sounded horrible. I hope I can do better.
There are other complications to infilling gaps also. For example a gap is explicit if you have received block 2 and block 4 appears, you know that block 3 is missing and can do something about it. The more complex case is when a complete loss of data happens, which you hope is temporary, and you have to infill for a while. Firstly you can’t simply wait for 60ms (in the case of DMR) and if no frame appears introduce a new one. Experience has shown that sometimes frames are delayed by quite a while, but will eventually appear and in the correct order. Therefore any infilling can’t be too aggressive otherwise you ignore real data, but it can’t be too relaxed as audio will be lost and/or the transmitter will switch off in the case D-Star and System Fusion.
What has struck me is that compared to DMR or System Fusion, the D-Star air interface does seem very simple and even under engineered, but working on it for the past seven years has taught me a lot, and that is feeding through into my DMR and System Fusion work. I would not have had the confidence to have considered this project before.