search

sm0svx / svxlink

Advanced repeater system software with EchoLink support for Linux including a GUI, Qtel - the Qt EchoLink client
http://svxlink.org/
Other
435 stars 173 forks source link

With AUDIO_DEV_KEEP_OPEN=1, CTCSS tone can be enabled but never disabled #615

Closed mweyland closed 1 year ago

mweyland commented 1 year ago

I will start by stating that I discovered the issue in svxlink v1.7.0 that ships with Debian Bullseye. I understand that this is old, but I believe that the problem persists in the current code base.

Steps to reproduce:

Doing that will result in the following: Periodic announcements will be transmitted without CTCSS (as it should be). Opening the squelch will key up the repeater, which then transmits with CTCSS (as it should be). But from that moment onward, any subsequent periodic announcements will be transmissted with CTCSS. That is in contradiction to what has been configured.

I believe this bug to originate in the enable() method of the SineGenerator class in LocalTx.cpp (copied from the current master): 

   void enable(bool enable)
    {
      if (enable == (audio_io.mode() != AudioIO::MODE_NONE))
      {
        return;
      }

      if (enable && (fq != 0))
      {
        if (audio_io.open(AudioIO::MODE_WR))
        {
          pos = 0;
          writeSamples();
        }
      }
      else if (!audio_dev_keep_open)
      {
        audio_io.close();
      }
    }

Enabling with enable=true opens audio_io and sends the first samples. In the case of AUDIO_DEV_KEEP_OPEN=0, disabling with enable=false closes audio_io and no further CTCSS samples are produced. However, in the case of AUDIO_DEV_KEEP_OPEN=1, a call to this method does nothing and further samples are produced as if the method was never called. Thus, in consequence, the CTCSS generator keeps running...

f5vmr commented 1 year ago

I believe that there is no issue with the latest svxlink, as I use it with bullseye, Debian 11, without any issues whatsoever. I've been updating it and using it for some considerable time now, with a small network of nodes.

There are a number of 'enhancements' that seem to create problems. But the basic system has worked from the time I began using it in 2007 and each update has only improved it. I wonder how you install it?

On Fri, 10 Mar 2023, 16:59 mweyland, @.***> wrote:

I will start by stating that I discovered the issue in svxlink v1.7.0 that ships with Debian Bullseye. I understand that this is old, but I believe that the problem persists in the current code base.

Steps to reproduce:

  • Set up an svxlink node with the repeater logic (standalone, no EchoLink or other modules required)
  • Configure TX_CTCSS=SQL_OPEN
  • Configure AUDIO_DEV_KEEP_OPEN=1 in the TX section and set a CTCSS_FQ
  • (Re)start the server

Doing that will result in the following: Periodic announcements will be transmitted without CTCSS (as it should be). Opening the squelch will key up the repeater, which then transmits with CTCSS (as it should be). But from that moment onward, any subsequent periodic announcements will be transmissted with CTCSS. That is in contradiction to what has been configured.

I believe this bug to originate in the enable() method of the SineGenerator class in LocalTx.cpp (copied from the current master):

void enable(bool enable) { if (enable == (audio_io.mode() != AudioIO::MODE_NONE)) { return; }

  if (enable && (fq != 0))
  {
      if (audio_io.open(AudioIO::MODE_WR))
    {
      pos = 0;
      writeSamples();
    }
  }
  else if (!audio_dev_keep_open)
  {
      audio_io.close();
  }
}

Enabling with enable=true opens audio_io and sends the first samples. In the case of AUDIO_DEV_KEEP_OPEN=1, disabling with enable=false closes audio_io and no further CTCSS samples are produced. However, in the case of AUDIO_DEV_KEEP_OPEN=0, a call to this method does nothing and further samples are produced as if the method was never called. Thus, in consequence, the CTCSS generator keeps running...

— Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/615, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAKA5CLCV4KNP3W7RPSYK3W3NMXBANCNFSM6AAAAAAVWWLIH4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

mweyland commented 1 year ago

Thank you for coming back to me!

I wonder how you install it?

I just used apt to pull the package from the Debian repo and proceeded with the configuration. It is the official Debian package. I just realized that this version is not as "old" (in terms of releases that would supersede it) as I thought.

I have been using svxlink for many years as well, but it is this very combination of parameters that triggers what I believe is a bug, and I have used svxlink differently in the past. I believe that the bug (if it exists) was introduced when the AUDIO_DEV_KEEP_OPEN feature was added.

Just in case I failed to make this point, the error only occurs when all the following conditions are met: (1) AUDIO_DEV_KEEP_OPEN is set to 1 (which is not the default), (2) svxlink is used to produce the TX CTCSS tone for when the repeater is in use, and (3) announcements are to be transmitted without the tone...

In an attempt to narrow this down: are you also using AUDIO_DEV_KEEP_OPEN=1 under similar conditions?

f5vmr commented 1 year ago

Ok, firstly I used uniquely the raspberry pi as the base of the operation, but there is no reason why another system cannot be used provided measures are taken to manipulate the input output and replacement of the gpio system used by the raspberry.

In the raspberry pi, I Install only the raspberry lite os bullseye operating system, using the raspberry pi.org installer, that correctly configured the SSH and WiFi (where necessary). Bullseye is Debian 11, that some installations stumble over.

I have developed a script on my GitHub, that pulls together all the updates and upgrades to the operating system, then all the ancillaries packages, then downloads the latest package from the GitHub from smosvx, installs it, and makes the changes to suit a user in the UK.

The command you refer to is not part off the current configuration, so I wonder where that arrives.

You can find my script on GitHub/f5vmr/svxlink_raspberry where there are full instructions, to either install it in English or French, at the same time, installing a full voices pack of either of the two languages. The configuration is compatible with the svxportal-uk.ddns.net:81 server, which Sally is underpopulated in the UK. Svxlink never seemed popular in the UK with many users gravitating to all-star link instead, which is limiting in some degree.

Apart from the final configuration of the gpio and sound card, it would suit most users. I am also close to perfecting a dashboard for further manipulating the configurations, also on my GitHub.

I'm quite passionate about the package, which is very overlooked.

I'll be happy to answer any questions.

Chris g4nab

On Fri, 10 Mar 2023 at 21:00, mweyland @.***> wrote:

Thank you for coming back to me!

I wonder how you install it?

I just used apt to pull the package from the Debian repo and proceeded with the configuration. It is the official Debian package. I just realized that this version is not as "old" (in terms of releases that would supersede it) as I thought.

I have been using svxlink for many years as well, but it is this very combination of parameters that triggers what I believe is a bug, and I have used svxlink differently in the past. I believe that the bug (if it exists) was introduced when the AUDIO_DEV_KEEP_OPEN feature was added.

Just in case I failed to make this point, the error only occurs when all the following conditions are met: (1) AUDIO_DEV_KEEP_OPEN is set to 1 (which is not the default), (2) svxlink is used to produce the TX CTCSS tone for when the repeater is in use, and (3) announcements are to be transmitted without the tone...

In an attempt to narrow this down: are you also using AUDIO_DEV_KEEP_OPEN=1 under similar conditions?

— Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/615#issuecomment-1464465040, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAKA5B3A4YMR646A5XEDD3W3OI5BANCNFSM6AAAAAAVWWLIH4 . You are receiving this because you commented.Message ID: @.***>

mweyland commented 1 year ago

Thank you for your response.

The command you refer to is not part off the current configuration, so I wonder where that arrives.

I don't understand what you mean by that. I did refer to quite a number of "commands" and I believe that all of them are documented and valid. In any case, I managed to replicate the problem in a fresh setup that I installed with your script. I used the 2023-02-21-raspios-bullseye-arm64-lite.img image and added the relevant /boot/ files (ssh, wpa_supplicant.conf, userconf.txt) by hand.

Then I followed your instructions; I installed git from the Debian repo, cloned your git repository and ran the installer. Unfortunately this was not a smooth process, mostly because of missing dependencies and issues when the installer is executed repeatedly after crashes. I did manage to install svxlink using your method though, and modified svxlink.conf according to the "Steps to reproduce" in the original description of this ticket.

We use this interface board, but I put together a config file that is completely agnostic of the actual hardware. I believe this to be purely a software problem. For my example config to work, you do need to install two alsa loopback devices. One (Loopback) will be for checking the audio produced by Tx1, and the other one (Loopback_1) will be for Rx1 to have something to listen to. On my Raspberry Pi 4, I achieved that using:

modprobe snd-aloop enable=1,1 index=2,3

The kernel module options may be different on your platform.

Then you can follow these steps to reproduce:

  1. Start svxlink with my demo config in place.
  2. Record from the Loopback alsa device in order to see what svxlink is doing. This can be done using, e.g. arecord -f dat -D plughw:CARD=Loopback,DEV=1 tx_audio.wav
  3. Wait for the first short announcement. svxlink is configured to produce these every other minute.
  4. Open the squelch to simulate traffic on the input. Rx1 is configured with a PTY squelch to /tmp/sql, thus you can write O to the pty to do that even in the absence of RX hardware.
  5. After a couple of seconds, Close the squelch.
  6. Wait for the next short announcement.
  7. Stop the recording.

Opening the resulting wav file in audacity reveals the following:

svxlink_bad_tone

The thick blue line is the 77.0 Hz tone and as you can see, it does not vanish after squelch close, leading to the undesired behaviour that I tried to describe originally. If I remove AUDIO_DEV_KEEP_OPEN from the Tx1 section or set it to 0 (which is the default, but as the documentation states, some hardware requires this to work properly, the problem vanishes and the CTCSS tone is removed upon squelch closure.

I believe this bug was introduced when the AUDIO_DEV_KEEP_OPEN feature was added, i.e. somewhere around commit 9d646af74876ad5ac82dbbea86e9aaa4062cb4dd. Furthermore, I believe that the bug is caused by improper case handling in SineGenerator::enable() as explained in my original post.

Best regards and thanks

Matt

svxlink.conf.txt

sm0svx commented 1 year ago

I can confirm this bug. Very easy to reproduce. Setting CTCSS_FQ=500 or something like that make it easy to hear the tone while testing. The tone will even be on after the TX has been turned off.