Incoming audio from server is blocked during local audio transmission

[dl7ata]

I am using a repeater configuration based on v1.9.99.36@25.05.1-69-g44f1dfce
My problem:
During announcements of long ident, weather or similar local, incoming audio from server transmission is blocked. I log shows incoming traffic, but no audio from that source comes through.

If server transmission starts a moment before long ident, all is fine. Audio comes through.

If the server transmission starts while long ident or another local announcement is transmitting , audio from server is blocked but log shows that the external station is transmitting.

Based on the documentation from
https://github.com/sm0svx/svxlink/blob/07708b5b1cc929bbd1b7beba0b8909caf16048e0/src/doc/man/svxlink.conf.5
I insert in all

• /usr/local/etc/svxlink/svxlink.d/*.conf -> MUTE_LOGIC_LINKING=0

In svxlink.conf [RepeaterLogic]: MUTE_RX_ON_TX=0

Btw - short ident is fine, didn't block anything.

Frank/DL7ATA

[dl7ata]

PS:
If there is only traffic from reflector/server, everything is fine. If there is local traffic during announcement, reflector traffic is blocked until announcement is stopped.

[DL2HAM]

I can verify the reported behavior. In previous iterations, repeater announcements and identification transmissions utilized an audio composite signal that ducked system audio to prioritize caller clarity. While this functionality remains intact for transmissions already in progress when those repeater announcements (long ident) start. However, any PTT initialization from a secondary operator is currently suppressed for the duration of that same system message.

[TRENT310]

So this seems related to the issue #732 I wrote about earlier. Currently SvxLink when set up to provide a local repeat path (as a RepeaterLogic), will prioritize local repeat audio from the same port, and mute any simultaneous audio coming in from the link (even if that "link" is just another port attached to the same device ie. localhost, and controlled by the same SvxLink instance). This is different from the behaviour offered from "traditional" analogue backplane repeater controllers where simultaneously occurring audio from other sources can either be mixed (at the same amplitude) or ducked (at a reduced amplitude). Right now, any call originating from the other port(s) whether physical or virtual (like EchoLink) will be missed and stepped-on entirely by the local users, without the situational awareness that there may be another station trying to make contact. The intent is that if multiple ports are linked together full-time by configuration, they should all receive the same user experience - that is they all receive the same IDs, the same system prompt messages, and if multiple ports are active at the same time, that they can mix the audio together.

While the behaviour may be desirable or undesirable depending on the particular implementation or application, this is why I suggest it should be configurable and not fixed hard-coded into the software. For example it may be necessary for a port which functions as a link hand-off towards another system (SimplexLogic), to suppress all identification and prompt or error messages.

For identifications, I suggest that there should be a "soft" and "hard" timer for identification, where a certain time window is allowed where SvxLink can delay the short or long identification to a natural break-in between transmissions, rather than starting the identification abruptly during an ongoing transmission as it does now. However, if a station is running on for an extended period of time, to meet regulatory requirements the "hard" timeout for identification may still play out as a mix. For example, if a conversation is actively occurring during the scheduled top of the hour (hh:00:00) long identification, that long ID is cancelled and say within a 2-minute window SVXlink will immediately follow at the next natural break in transmission (loss of COR/TOR/VOX) with a short identification (without time announcement, since it will be incorrect). If a transmission is extremely long-winded and exceeds that 2-minute window, then the short identification will play as a mix at hh:00:02 regardless. The timings mentioned are variable and just for discussion purposes.

As with my other cases on here have been left open without development team comment, so perhaps this is not really the best forum for discussing the various real-world deployments of SvxLink and whether it aligns with the direction of the software project. I figure they are left open and unaddressed, since it is currently "operating as designed" - but these reports are more so encouraging the reconsideration of what that "design operation" should be, as part of a road map for SvxLink. If it is more helpful I can re-post this topics I have started, on the groups.io site instead. However having them documented on github makes it easy to reference various similar report cases, or should the feature request get addressed it can be cited in the release notes. I think SvxLink does have a lot of potential in terms of how it can be adapted since once the hardware platform is built and deployed now these are little software refinements to achieve feature parity with "legacy" system controllers and beyond.

[dl7ata]

Hi Kevin,

I think it's less complex than you've described. The parameter for lowering the volume of announcements already exists. It works fine as long as there's no local repeater input.

Therefore, I consider it a bug. That's why I think it's appropriate to open a ticket here on the developer platform.

I'm confident that Tobias will respond here.

[f5vmr]

In the software, I use the Module inhibitor MUTE_LOGIC_LINKING = 1 so that if one of the modules is activated, there is no interuption to Network traffic already active on the reflector. This is so that a current QSO across a talkgroup on the svxreflector, is not interupted by a user activating METARINFO or an incoming EchoLink connection does not interupt the flow. Such activations isolate the node upon which they are activated, until the module activity has ceased, that permits the node to rejoin the reflector world again. This is part of the design. If such a repeater would defer to = 0 on this line, I would ask that is be restored, only as a courtesy. If the Tx is already running the announcements are reduced by the factor of FX_GAIN_LOW if correctly set - in fact I reduce mine from -12 to as much as -19 as often then -12 is too loud.

See you on north.america.svxlink.net or ukwid.svxlink.net perhaps.

[dl7ata]

Just to clarify the bug Chris:
Only the local traffic of the repeater triggers the interrupting of the incoming network traffic. It is not necessary for a local module to be activated.
In my opinion, the parameter MUTE_LOGIC_LINKING has nothing to do with the bug.
Tobias might be able to shed some light on that matter.