Audio synchronisation on multiple (remote) TX
Brought to you by:
sm0svx
We are planning to make a single frequency network where all the transmitters must be sending the same audio at exactly the same time.
For this some timestamps (GPS source?) should be send together with the audio from svxlink to all TX sites and all audio should be delayed to give a total static value.
An example of this kind of network is here: http://www.coversity.nl
They use their own hardware and software, we would like to use SvxLink.
Is this on FM? Even if you manage to sync the audio exactly, won't there be distorsion when the carrier from two different repeaters in range mix? I found a YouTube video testing the Coversity network. There is an annoying sound in the background. Maybe it's some other interference?
http://www.youtube.com/watch?v=JDnjGTgQvhU
Yes this is on FM, the annoying sound is not from the network but a local
interference and he is listening on a distant repeater.
The idea is to get the audio as identical as possible, best way is probably
using DDS, but for now we want to test with the equipment we have.
On Sat, Mar 22, 2014 at 4:45 PM, Tobias Blomberg sm0svx@users.sf.netwrote:
Related
Feature Requests: #30
Here are some locally discussed ideas for implementation:
First, it is probably easiest to connect the local repeater at the central
site via remotetrx on 127.0.0.1 instead of directly. This makes the system
symmetrical. Not sure if this is really required.
Second, prerequisite is to have good timesync on each site. Fortunately this
is easy today with a GPS receiver with PPS output and ntpd. It is also best
to lock the transmitter frequency to GPS as well. Those two functions can
be implemented using a (surplus) GPSDO.
Let's assume we have a working system with Voter that results in a stream
to transmit on all the sites simultaneously. For each packet we take a
timestamp (in nanoseconds or microseconds), add a delta-time to this, and
put the result in a header of the packet transmitted to all transmitter sites.
That is the "desired time of transmission" of this packet. The delta-time
should be at least as large as the largest latency of the network.
Upon reception, the transmitter site can calculate the difference between the
desired transmission time and the current time. It can also request the
delay that a sent audio packet will endure in the soundcard using the Alsa
function snd_pcm_delay(), which will return the number of frames (samples)
that are presently in the output queue, which it multiplies by the sample time.
When the difference is larger than zero, some extra samples will have to be
added to the front of the packet (copies of the first sample), when it is
less than zero, some samples have to be deleted.
Then the packet is sent to the soundcard, and when everything is
right the samples will leave the soundcard at exactly the correct time.
The transmitter sites will average the above number of correction samples
(inserted or deleted), and send it back to the central site regularly.
The central site checks if remote sites are reporting deleted samples
indicating that the latency on the network was larger than the delta-time
added in the beginning, and it quickly adjusts the delta-time in that case.
When all sites are reporting high numbers of added samples, indicating the
delta-time is larger than the worst network latency, the central site slowly
decreases the delta-time (maybe deferring that until a silence event).
This way, the system automatically adapts to the network topology while
adding minimal delay.
Another approach would be to use Jack2 (jackdmp) with the NetJack2 feature.
It looks like this sound system already has the capability of synchronized
sound output on distributed systems, although it has to be evaluated how good
the synchronization is (I have yet to find any specification).
Also, this is of course a standalone protocol that would run in parallel with
the existing protocol for signalling, and it probably has security challenges
when used on the internet (that could of course be avoided using a VPN).
Anyway, the implementation could provide insight in how synchronization can
be achieved.
It's always hard to develop close to real-time functionality on a non real-time system so it will be a challenge. I guess you'll have to keep the time jitter below like 100us to not get artifacts in the combined signal from multiple transmitters.
I think the best way to go is to implement the real-time stuff outside of SvxLink to have full flexibility. Adding time stamps to the audio stream would probably require changes to all audio components in SvxLink and this is not desirable. I will probably not accept patches that change the audio pipe infrastructure.
One way forward is to use the UDP "audio device" to stream audio into an external application that handle the real-time stuff. So in SvxLink, you only set up a local transmitter with a UDP audio device. The external application is then responsible for timestamping and communicating to the other transmitter sites.
It would also be possible to implement it as a new type of audio device instead of using UDP. If Jack can be used, this is probably the most straight forward solution.
A third alternative is to implement it as a new transmitter type to get full control of all aspected of a transmitter (e.g. DTMF and CTCSS generation). I guess quite small changes to NetTx and the protocol would be required but on the RemoteTrx side it's probably best to write something especially tailored for real-time from the ground up.
Anyway, I'd probably go for the UDP solution to start with. You could also then easily stream from other sources than SvxLink for testing (using socat for example).