On Sunday 04 May 2014 12:11:20 Rob Janssen wrote:
> SM0SVX wrote:
> > 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?
Hmmm, my thought was that you could activate the PTT when there is audio to
send on the remote site but SvxLink is not always sending audio even if the
PTT is activated, so that may not work.
When the patch Adi is working on is done you will be able to use a PTY to get
PTT info into your external application. Then you can send PTT info in your
own network protocol. I think the patch is close to done. Adi?
The third alternative is of course to use the NetTx code as a base. Maybe you
don't need to change much there to implement what you need? Maybe just add a
timestamp if you're using a static time delay to start with? You may also want
to send the audio via UDP. That have been the thought from the beginning but
have never been implemented.
> 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)
Yes, that could be a problem.
The most straight forward solution is to use an extra sound card but that may
not be desirable. However, it is the most trouble free way forward since you
get full control of the audio device. I think it would be your best bet until
you know that your time sync code is working. After that you can go forward
with other solutions.
It could be possible to share an audio device by using ALSA plugins but that
may get you into trouble with real-time performance. I don't know. Some sound
cards/dirvers may support multi open but I have no experience with this.
If you can incorporate real-time functionality into
AsyncAudioDevice/AsyncAudioDeviceAlsa without modifying the audio pipe API but
by only adding some new methods to the class, that may be a way forward.
I strongly suggest that you start out with a separate sound card though.
> 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.
73's de SM0SVX / Tobias