> The correct solution really is to use unsquelched audio and as a workaround
> being able to set the level above which the signal level is considered bogus
> using configuration.
I see you have implemented this in the trunk version.
Now we have the trunk version running on both the main and receiver site and things are
looking good. It has not crashed yet, except when I played with the echolink rogerbeep.
> As you may have seen, Adi (DL1HRC) is working on an extension where you can
> interface to hardware using external scripts that talk to SvxLink through
> PTYs. Right now it's for squelch, ptt and dtmf but the concept should be
> possible to extend to signal levels as well. Then an external script could be
> used to read the signal strength from your hardware and this is then written
> to the slave end of a PTY which SvxLink opens specifically for communicating
> signal level measurements.
> As for combining different types of signal level detectors, this will have to
> be something for the future but I guess it would be fully possible to
> implement using the same structure as for the voter: a signal level "detector"
> type that aggregate the estimate from multiple sensors.
Ok, will look to that later.
Now, I am plannning to write a solution for our multi-transmitter station (enhancement #30).
I'll try the solution with the UDP audio stream first. I have the following questions:
1. when we use the UDP audio stream and our own daemon to distribute and synchronize
the audio, can we still use the svxlink NetTx to control the PTT without sending the audio
via that path as well? (wasting bandwidth) Maybe a "NULL" CODEC?
2. when our own network daemons are running and having the ALSA interface to the soundcard
open for output, will svxlink not get confused about the accessability of the card and/or its duplex
capability? If possible, we would like not to have a mandatory startup sequence and/or to
close the soundcard whenever there is no audio.
(I would like to have the receive side directly connected to svxlink as it is now)
I looked at the Jack API but it looks like it is not so easy to write a AsyncAudioDeviceJack.cpp
at least not for me. Jack is not based on open/read/write but is using callbacks for all IO.
Even if it could be done, another issue with Jack is that it is designed for music and assumes
there is always a continuous stream of audio to be played. Of course fillers can be inserted,
but it will mean there always is full-bandwidth network traffic even when the repeater is idle.
So for now it looks like it is easier to write a custum solution via UDP/daemon/Alsa.