ASL3 Warning From chan_usrp.c

App_rpt-users
1

Using a RPi5 I installed DVSwitch on the same instance as ASL3 and linked it to ASL3 using chan_usrp. The following message is repeated for each transmission received from DVSwitch in the asterisk log:

WARNING[265959] chan_usrp.c: Channel usrp/127.0.0.1:34001:32001: Receive queue exceeds the threshold of 320

I tried to determine the origin of this message in the source code but have been unsuccessful.

I also notice that received audio from DVSwitch is mangled at the very beginning of a received transmission but soon becomes normal. Possibly a result of the same issue.

Is there a known resolution to this issue? Can it be resolved in configuration, or a change to the source code?

2

I have this on one of my nodes as well…

3

Line 598 of …/app_rpt/channels/chan_usrp.c logs this message.

I don’t see any open GitHub / app_rpt reported issues. Can you create a new issue? :slight_smile:

4

Issue recorded on Git…

5

Have you looked at your dvswitch logs for answers ?
On the surface, it does not look like a asl3 or usrp error but the input stream in error.
USRP is not satisfied with it. Hence the message spew from the channel driver.

6

This is a representative sample of MMDVM log

M: 2024-12-21 13:59:47.928 YSF, GPS Position from K0EHT-RON  on radio=0x34 is lat=39.208000 long=-94.679665
M: 2024-12-21 14:00:11.734 YSF, received network end of transmission, 24.7 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-21 14:00:17.009 YSF, received network data from KE8EFQ     to ALL        at KU0S/GW
I: 2024-12-21 14:00:17.009 YSF, Lookup call KE8EFQ returned id 0 -> 1234567
M: 2024-12-21 14:00:18.499 YSF, GPS Position from KE8EFQ     on radio=FTM-100D is lat=41.188000 long=-81.976997
M: 2024-12-21 14:00:25.305 YSF, received network end of transmission, 8.4 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-21 14:00:31.876 YSF, received network data from K0EHT-RON  to ALL        at KU0S/GW
I: 2024-12-21 14:00:31.876 YSF, Lookup call K0EHT returned id 3129461 -> 3129461
M: 2024-12-21 14:00:32.665 YSF, GPS Position from K0EHT-RON  on radio=0x34 is lat=39.208000 long=-94.679665
M: 2024-12-21 14:00:36.566 YSF, received network end of transmission, 4.8 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-21 14:03:14.379 YSF, received network data from W1KN       to ALL        at BM3104
I: 2024-12-21 14:03:14.379 YSF, Lookup call W1KN returned id 3154382 -> 3154382
M: 2024-12-21 14:03:14.849 YSF, received network end of transmission, 0.9 seconds, 0% packet loss, BER: 0.0%
M: 2024-12-21 14:03:21.339 YSF, received network data from W1KN       to ALL        at BM3104
I: 2024-12-21 14:03:21.340 YSF, Lookup call W1KN returned id 3154382 -> 3154382
M: 2024-12-21 14:03:24.460 YSF, received network end of transmission, 3.7 seconds, 0% packet loss, BER: 0.0%

This is a representative sample of Analog log:

I: 2024-12-21 14:18:27.121 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ
I: 2024-12-21 14:19:01.064 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX
I: 2024-12-21 14:19:47.769 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ
I: 2024-12-21 14:20:16.067 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX
I: 2024-12-21 14:21:01.926 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ
I: 2024-12-21 14:21:49.294 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX
I: 2024-12-21 14:22:01.050 Begin TX: src=3119338 rpt=319639911 dst=9 slot=2 cc=0 call=N0EHQ
I: 2024-12-21 14:22:27.360 Begin TX: src=1234567 rpt=319639911 dst=9 slot=2 cc=0 call=N0OMX

No errors “E:” in those files or YSFGateway (where the switch is tuned).

7

This is somewhat meaningless.

A sample when the USRP error is given might mean something.
Analog bridge is the last to handle the stream before sent to USRP.

You really should be presenting this to those at dvswitch for help.
It does not appear to be a asl issue.

8

If all the logs repeat the same types of data, then one is not going to identify an error.

There are no errors in the DVSwitch log files.

9

Assuming the usrp channel driver is working correctly,
It is not getting data correctly and is the one telling you that fact. The error.
It gets it’s data from analog_bridge.

By structure, That is all I can say about it. You will need to ask

1 Like
10

We are seeing the same warning as well.

[2024-12-23 09:05:50.336] WARNING[1142] chan_usrp.c: Channel usrp/127.0.0.1:34001:32001: Receive queue exceeds the threshold of 320

In our case, it appears on inbound DMR voice calls longer than a few seconds, but does not appear to cause any issues with audio on the analog output side of things.
It really sounds like the analog driver is not keeping up with the stream (queue is being over run by the Analog_Bridge), but it must be “really close” to 320, otherwise I would think we would notice audio problems…

11
12

I guess I stated it “wrong” - USRP is the software not keeping up with the stream… Nothing has changed with DVSwitch or the Analog_Bridge, but ASL has. Why would we suspect it is a problem with Analog_Bridge?
I suppose at this point it’s more of a log filler than a problem.

13

I’m curious about something.
In your DVSwitch setup, are you using Analog_Reflector between Analog_Bridge and ASL?
If not, have you tried disabling metadata export from Analog_Bridge to see if anything changes?
in /opt/Analog_Bridge/Analog_Bridge.ini, find the line;
exportMetadata = true ; Export metadata to USRP partner (transcode setups require this)
Change true to false, then
systemctl restart analog_bridge

If you are sending directly from Analog_Bridge to ASL, you don’t need this. However, if you are sending to Analog_Reflector, then sending Analog_Reflector to ASL, you should leave it enabled to maintain metadata.
This metadata sends a chunk at the start of a transmission, which comes out as a sort of popping sound if it isn’t intercepted by Analog_Reflector, or disabled entirely.

I wonder if this changes the behavior of ASL’s USRP driver when fed by DVSwitch Server or not.

14

Thanks for pointing out exportMetadata. As OP in this thread, I mentioned there was a glitch heard at the start of received transmissions. With exportMetadata=false, the glitch is gone, but the asterisk log warning messages remain.

15

So channel driver is generating the error here:

The warning is NEW to the driver code as of October 26, 2024:

I’d say the warning is misleading for sure → It says it has exceed the threshold then give us the USRP_VOICE_FRAME_SIZE instead of QUEUE_OVERLOAD_THRESHOLD

Since this is a “new” error, it may have been occurring forever as well, we just didn’t know it.