When CODEC=NULL is used, transmitter not keyed for announcements

[pe1chl]

We now have the co-channel system running. For the second transmitter, at the main site there is a remote tx with CODEC=NULL [NetTx_HVS] TYPE=Net HOST=44.137.42.61 TCP_PORT=5210 AUTH_KEY="(key)" CODEC=NULL

On the remote trx this is used to key the transmitter: [TxUTR] TYPE=Local AUDIO_DEV=alsa:null AUDIO_CHANNEL=0 PTT_TYPE=SerialPin PTT_PORT=/dev/ttyS0 PTT_PIN=RTS PTT_HANGTIME=3000 TIMEOUT=7200 TX_DELAY=0

The audio is transmitted separately using my co-channel addition. It works fine for normal QSO transmitting, but when the repeater is keying up only to transmit an announcement (ID), the second transmitter does not key up. In the svxlink logfile there normally is a message like: Thu Sep 4 09:50:00 2014: NetTx_HVS: The transmitter is ON This does not appear when the transmitter is to be keyed for an announcement. (incidentally, this message also appears for a remote trx that is not connected at that time!)

When I replace the CODEC with a real one, for example OPUS, it suddenly works OK. (but of course the audio is compressed, sent and decompressed only to end up in alsa:null)

[pe1chl]

I have researched this problem and it turns out it is caused by the TX_AUTO mode of transmit handling. The transmitter can be controlled in 2 ways: it can be turned ON and OFF explicitly, which is happening in "QSO mode" (the repeater being keyed up by a received signal), and it can be automatically switched depending on the availablility of audio to transmit. This is apparently used when playing announcements without input signal. Looking in the code there also appear to be some other cases that do not occur in our configuration.

When I requested the NULL CODEC, I was not aware of this situation. The combination of the above transmit handling and the NULL CODEC of course cannot work: when configuring the NULL CODEC there is no audio to transmit and the TX_AUTO mode will fail.

I think the options are to remove the NULL CODEC or to remove the TX_AUTO feature and always control the transmitter explicitly. The latter is probably much more work and prone to introduce new bugs. So it appears better that we just live with the duplicate audio transmission in our special situation of using co-channel transmission.

[sm0svx]

I think latest master will now solve this issue.

[pe1chl]

It does not compile here... [ 23%] Building CXX object async/audio/CMakeFiles/asyncaudio.dir/AsyncAudioDecoder.cpp.o In file included from /home/pi2nos/svxlink/src/async/audio/AsyncAudioDecoder.cpp:52:0: /home/pi2nos/svxlink/src/async/audio/AsyncAudioDecoderNull.h: In member function ‘virtual void Async::AudioDecoderNull::writeEncodedSamples(void, int)’: /home/pi2nos/svxlink/src/async/audio/AsyncAudioDecoderNull.h:153:38: error: variable-sized object ‘samples’ may not be initialized make[2]: ** [async/audio/CMakeFiles/asyncaudio.dir/AsyncAudioDecoder.cpp.o] Error 1 make[1]: * [async/audio/CMakeFiles/asyncaudio.dir/all] Error 2 make: * [all] Error 2

This is using: g++-4.7.real (Debian 4.7.2-5) 4.7.2

[sm0svx]

Ok. I obviously used an initialization method that is too new for older compilers. Now using memset instead.

gcc version 4.9.2 20150304 (prerelease) (GCC)

[pe1chl]

Ok now it is compiling... will test soon. We use Debian Wheezy and it comes with the gcc listed above. I see 4.9 is available as a backport, could install that when it is recommendable.

[sm0svx]

My goal right now is for SvxLink to compile on CentOS 5 which use the following compiler.

gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)

I usually test this before releases but not at each push to master. It could probably be automated though. I'll keep the requirement for CentOS 5 as long as it does not impose a major inconvenience. CentOS 5 as a distribution is supported until 2017 so after that date support will definitely be dropped.

CentOS 6, which is supported until 2020, use gcc 4.4.7.

At some point I'd like to start using C++-11 features and then I'll have to reevaluate which compiler versions to support.

[pe1chl]

Ok... I thought maybe a newer compiler could avoid some bugs in code generation, but when you test with older versions it should be OK. Code is now running on 6 of our systems, will continue tonight but first I have to go to QRL. It appears to work OK including keying via NULL codec.

[pe1chl]

It works OK, so the ticket can be closed. Of course a solution like this depends on integer size and endianess, but in our system we have no issues with that (we use only i686 amd64 and armv6l architectures and they are compatible in this respect).

[sm0svx]

Yes, it is indeed very sloppy coding and the implementation should be improved.

[sm0svx]

That will do it I hope.

The new implementation is not compatible with the old one so unfortunately you need to upgrade all nodes again.

[sm0svx]

Are you running the new implementation now, @pe1chl? Does it seem to work?

[pe1chl]

Yes it appears to work OK