sh123
commented
5 years ago @M0IQF, I guess it happens when svxlink sends audio from the RIG into the FRN server. Currently, FRN module goes into the IDLE state after list was processed, thus interrupting audio stream going from rig into the FRN server, list needs to be processed anyway, because the same connection is used for control and audio streams.
Solution might be to save the state if in TX and restore it after list was processed instead of going into the IDLE state or go into the IDLE state only when squelch is closed.
It would be helpful if you post svxlink console log of this issue with FRN module debug level turned on.
I haven't tested it, but workaround might be to replace block in QsoFrn.cpp line 394:
{
sendVoiceData(send_buffer, send_buffer_cnt);
send_buffer_cnt = 0;
}
else
{
samples_read = count;
break;
}to just
sendVoiceData(send_buffer, send_buffer_cnt);
send_buffer_cnt = 0;this will cause audio to be send to FRN as long as squelch is open even if state has been changed to IDLE.
M0IQF
f5vmr
valerysvl
Hi, I was using "client FRN" on a server with a lot of other clients, and I've seen an issue. The problem is that the audio cuts while receiving the update client list. It isn't an issue in the RX mode, but then you start transmitting it cuts the modulation and the server goes quiet without tuning the PTT off. Is there a possibility to erase the line of code which is responsible for the receiving the client list in the console mode, which isn't really necessary? P.S: To visualize this issue, you can go to the test room with two clients, and record with one for around 10 seconds. After 5 seconds, log out with one of the clients and listen to the recording. It will only record the first 5 seconds and the remaining 5 will not be recorded, because of the update of the client list.