The problem is that even after installing all the necessary prerequisites, it is not possible to activate the chan_simpleusb and chan_usbradio modules in menuselect.
What could be the reason?
Are you following these directions: Source-Based Installation - AllStarLink Manual
I tried to compile according to this manual. But the problems started when I tried to execute rpt_install.sh. This script gives an error when trying to copy files to the folder with asterisk sources.
I transferred the sources and applied the patches manually.
The problem is that I only need to make a few changes in app_rpt.c and xpmr.h and it would be preferable not to reinstall asterisk but only replace app_rpt.so and chan_usbradio.so, since when installing from scratch, asterisk is installed not exactly as it is installed in the default image.
I haven't recently verified the steps in the " Source-Based Installation (using phreaknet)" document. But, I can tell you the "build-asl3" steps do work ... 'cause I use them nearly every day.
Please feel free to reach out to me if you need a bit more help.
I finally got through it by following the manual.
But unfortunately, this did not solve any problems.
The app_rpt.so file turned out to be 3 times larger than the file included in the RPi image. Asterisk does not work correctly, audio is completely unusable, continuous interruptions.
When trying to replace the file included in the RPi image with this file, asterisk does not start.
How else is it possible to get a distribution as close as possible to the default image for RPI, which is incredibly stable, but with a custom app_rpt?
A number of developers build from source, use it, and test it all the time. The size difference is likely the debugging symbols at first guess. What are you trying to customize in app_rpt? If you're trying to splice in code developed for old versions, it's doubtful that will work as the internals of app_rpt have undergone major transformation.
"/dev/dsp1 needs to exist for chan_simpleusb and chan_usbradio to work."
could that be your problem?
GeorgeC W2DB
My major pain is these settings.
(rpt_config.c)
case DLY_UNKEY:
if (wait_times)
interval = retrieve_astcfgint(myrpt, wait_times_save, "unkeywait", 50, 5000, 1000);
else
interval = 1000;
break;
case DLY_LINKUNKEY:
if (wait_times)
interval = retrieve_astcfgint(myrpt, wait_times_save, "linkunkeywait", 500, 5000, 1000);
else
interval = 1000;
break;
It is extremely annoying when a simplex node has a tail of 2 seconds after remote unkey before the cortesy tone and the transmitter is turned off. I reduce this interval to 300 milliseconds or less. On ASL2 this worked perfectly, except for rare problems with connections that had a high ping.
Second is additional types of MDC1200 transmissions.
Third, is the routine of voice messages. I adapt the sequence of playback of voice files during voice announcements to my needs.
Why do you need to change the code for unkeywait and linkunkeywait rather than just defining them in rpt.conf? Your method won't break anything but seems unnecessary? I might be missing something.
You'd have to provide more info about your other two items.
But, overall, none of that should be causing any performance issues or compile issues. Given that a number of people are building from source it might be something with your setup? Can you provide the complete of steps you're using to build?
Both values in rpt.conf are set to 0, however the tail on the simplex node is 2 seconds. Fixed by changing the third value (1000) to 50 and 200.
I can see why you'd need to change the source code to set a lower linkunkeywait value. For that variable, the min value is currently set at 500 [ms] ... so you would not be able to set a value of 300 in the configuration file. Simple enough to fix. File and issue (or pass along a PR) and we'll get the change merged in.
Need more info about the MDC1200 transmission issue(s).