[Jack, N5JFP]

I’m running a new Pi-Repeater 1x, and I’m having some difficulty getting the audio out adjusted properly.

The only thing that gives me the proper transmit audio is Alsamixer.

When I do use it, I adjust the PCM setting, and that makes my audio just the right volume. Of course, using Alsamixer doesn’t permanently set the transmit audio level.

My main question is, what setting in the svxlink.php file associates with the PCM setting in Alsamixer? If I can find that I can set the proper audio level and be done with getting this thing tweaked.

[Aaron, N3MBH]

Hello Jack,
Let me see if Dan can make some comment on here. Alsa mixer settings should stick…unless there is something else going on.

73,
Aaron – N3MBH / WRFV871

OpenRepeater is offered free of charge. Find out how you can support us.

[Dan, KG7PAR]

I agree the settings for alsamixer should stick.

Can you elaborate on what events are causing the settings to change? Are you setting them and then rebooting/power-cycling/reconfiguring ORP/?.

By default the settings I believe are around 70% in alsamixer and this should be plenty loud. Beyond this it sounds like potentially a deaf TX radio, is the input levels on your tx rig programmable? We have encountered this a few times now where the input levels are incorrect inside the radio.

Dan

[Jack, N5JFP]

When I try setting the audio in Alsamixer, I have to set the PCM level to about 86 to get the audio loud enough. But, the settings only stay until I either reboot/power cycle the Pi. When it comes back up, the settings revert to normal.

My receive and transmit radios are both Motorola CDM1550LS+. I use them on all digital modes for my repeater, and they work flawlessly.

I have both set to flat audio, and since I’m using the MMDVM/Pi controller together, I have them split up settings wise. They share a common audio input (flat audio receive), but for transmit the MMDVM uses the default flat audio transmit pin, and the Pi controller uses the external mic audio input, also set to flat transmit. I also split the PTT off for the Pi controller, so it won’t interfere with the MMDVM.

As far as input levels to my transmit radio, I’m not sure how to adjust those in CPS. The voice audio actually comes out somewhat ok, but since the Alsamixer setting won’t stick I can barely hear the repeater voice female speak or the CW ID.

I’ve adjusted all of the physical pots, and they’re dialed in pretty good right now.

But to reiterate, the Alsamixer settings revert back to the default levels when I reboot. Matter of fact, every time I reboot, I have to go into the interface tab and reselect the pre-setting for the Pi 1x controller, before it will receive or transmit.

I’m so confused about all of this! Getting the MMDVM tuned up and working well on 5 digital modes was easier than trying to get the Pi controller working properly!

[Dan, KG7PAR]

@arron,

Can you double check that the update settings routine doesn’t rewrite the alsamixer levels? I know we set them when loading the preconfigured settings, but I am not sure if they get written again any time the settings are recompiled due to a setting change. This might be an issue behind this depending on how that was implemented.

@Jack,

Assuming my comment to arron is NOT correct, This sounds like an alsa/kernel issue more than anything in hardware. I have ran into this with some experimental hardware a while back so I understand what you are facing. Very frustrating indeed. Admittedly I never have needed to adjust the mixer from the default for my setup, so I can’t say for sure this isn’t a bug.

try setting the alsamixer settings and then execute

sudo alsactl store

This should force the settings into the file immediately.

Reboot and see if the issue persists

If the issue persists, issue the following command

sudo systemctl disable nginx,

This will disable the Open Repeater webserver (just to make sure its not stepping on your toes)

and reboot again.

Hopefully one of these will help to narrow down where the issue is originating

Now for the synthesized audio, This is actually opposite of the common issue, where the synthetic voice is very loud and the RX is quiet. I am not sure how this could be quiet while the voice portion is okay. I believe there are some commands in the config file that can be used to adjust all this, but I haven’t played with them. It would take some trial and error

Some commentary related,

We have found that pulling the power will defintely cause the alsamixer settings to not be written to file. It is best to issue a “shutdown”, allow sufficient time for everything to come to a complete stop before power cycling. Once the settings are locked in, you can power cycle, although there is well documented evidence this is a risky behavior, but sometimes can’t be avoided. I have personally corrupted a few SD cards by doing power cycles unceremoniously.

Strangely enough, it seems to like messing with the audio and I2C bus the most from my personal experience.

If this continues to be an issue, I would suggest writing down your settings and reimaging the sdcard or grabbing a seconds SD card (Be sure to use name brand high speed ones) and using it to experiment with. On my setup that acted this way, this reimaging of the card immediately cleared up the problem after going several rounds with the tech support for the product thinking it was a driver issue.

In the CPS utility, there is a gain (-dB as I recall) setting for the external mic connector on the back of the radio, as I recall we had to turn this up almost to maximum with the sound set at 60% (the previous default in the ICS images). We then found out through trial and error with the OR image that on the CDM radios we had, that the 70% defaults should be plenty loud. On the units I touched for a customer, this mic setting was turned way down, not sure if that is default or someone had messed with it while experimenting.

Hopefully some of this will get you going. This should be solvable, just need to figure out which (virtual) knob to turn.

[Dan, KG7PAR]

As a missed note, to reenable the OR webserver issue the following command

sudo systemctl enable nginx

and reboot to get back to normal behavior for the web UI.

[Jack, N5JFP]

OK, I tried using the command to get the Alsamixer settings to stick, and no dice. I also tried the commands to disable and enable the server, but this runs me into another issue.

First, seems like the suggestion to turn up the mic gain worked well. Its now plenty loud (voice and synthesized voice). Now I just need to adjust the POTS on the board because the incoming voice audio is TOO loud now! (Better than it was though).

Whenever I reboot, the repeater will not auto start. Plus, I also have to go into the interfaces portion and reselect my board under the board presets, before it will even work. I have to do that whether I reboot, power cycle, etc. I’m guessing that setting should be sticking right? I also have to reactivate echolink too.

I do have another question to. As far as CTCSS, where would I put that line to have it go out with the audio? I tried twisting it with the audio out, and it didn’t work. Also, on the CDM1550 I don’t think there’s an option to hook up a CTCSS line to transmit it. Since I use flat audio, it won’t transmit a PL. I want to try and set a transmit one so those who don’t use digital won’t have their ears blasted anytime there’s a digital QSO

[Dan, KG7PAR]

Okay, first problem is solved then, you now have audio! Hazaa!!

For the second one, this is an issue we recently identified as a race condition in the system booting up sequence. I will need to chase down the file path, but its a simple file edit once I find the details of which file to edit. It always takes me a while to find that pesky file.

https://github.com/OpenRepeater/openrepeater/issues/57

We haven’t implemented this yet in our latest beta, but it will be done soon. The fix has been tested by the one developer and it fixed his system that was failing to come up and I have also encountered this.

As for the CTCSS, you should be able to put it directly in with the audio out, unless the rig blocks its. again in svxlink (not the ORP gui) there is the option to add in the PL tone synthetically. I don’t know that any of us have played with this portion of the software yet, but I am not aware of any bugs in the core software against it functionally.

[Dan, KG7PAR]

Okay, I heard back that this is the service file that needs patched. In the units section add the after statement below to prevent the race condition.

This should keep the repeater from failing to start normally.

/lib/systemd/system/svxlink_gpio_setup.service

[Units]
…
After=network.target
…

[Jack, N5JFP]

Very interesting!

After I added that in to that file, I noticed that the audio suddenly became raspy (and overdriven sounding). I checked the gain in my transmit radio, but then on a hunch I went back into Alsamixer, and the changes that I made that didn’t stick before, now are stuck. I had to set it back to the default level, and the audio returned to normal.

Now when I reboot, the settings stay and I don’t have issues with having to reset everything everytime. So, it appears problem solved.

Now, I do have another thing, but its not a problem so much as a preference. Is it possible to set courtesy tones based upon what module things are coming in from. In other words, 1 tone when I’m on RF, and a different one, say when audio comes in on Echolink? If so, I’d love to set different ones.

[Author]

Posts