search

sm0svx / svxlink

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

Audio synchronisation on multiple (remote) TX [sf#30] #85

Open sm0svx opened 10 years ago

sm0svx commented 10 years ago

Reported by pe1rjv on 2014-01-29 08:22 UTC 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.

sm0svx commented 10 years ago

Commented by sm0svx on 2014-03-22 15:45 UTC 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

sm0svx commented 10 years ago

Commented by pe1rjv on 2014-03-24 11:11 UTC 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:

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

Status: open Created: Wed Jan 29, 2014 08:22 AM UTC by Paul Adriaanse Last Updated: Wed Jan 29, 2014 08:22 AM UTC Owner: nobody

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.

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/svxlink/feature-requests/30/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

sm0svx commented 10 years ago

Commented by pe1chl on 2014-04-29 18:15 UTC 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.

sm0svx commented 10 years ago

Commented by pe1chl on 2014-04-30 08:40 UTC 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.

sm0svx commented 10 years ago

Commented by sm0svx on 2014-05-03 10:34 UTC 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).

pe1chl commented 10 years ago

In the meantime we have something running. Approach has changed a bit:

The general operation is as described earlier, but now the timestamps are obtained on reading the Loopback device (which means they are not affected by process scheduling after a read), and the timestamps on the output are use both to determine the time offset of actual output and to calculate the actual sample rate of the output soundcards in the different transmitters. The SRC is set to the ratio determined by the actual sample rate and feedback of the actual offset, so the output smoothly tracks the timestamps in the received packets without the jitter caused by inserting/deleting samples, and the inaccuracy of the card sample clocks is no longer a factor (we observe +/- 5Hz error at 48000Hz for typical soundcards and onboard audio).

On the air, it does not work that well. We are experimenting...

pe1chl commented 9 years ago

We have found the reason why it did not work OK. Our soundcards are too feature-rich. They have an onboard DSP for postprocessing that causes a delay, and as we are using two different cards the delay is different as well. We will replace the soundcards with dumb ADC/DAC-only cards. Until then I have added a parameter to set a fixed delay (just a value added to the timestamp) in my software, and we remotely measured the audio on a scope and removed the time difference. There was only a 316us error but it caused big trouble. Now that our timing error is below 20us or so it works fine! This shows that the system can only work when everything is tweaked for best performance.

I am still testing if it can be made to work on a CubieBoard2, but I encounter some limitations. Source is available from me for those who are interested, and will be generally released when it is more stable (currently I still make changes every day)

pe1chl commented 9 years ago

In the meantime we have switched our soundcards to dumb C-Media CMI8738 based cards and the timing problems are all gone. When I use my calibration tool to measure the timing difference between transmitters I get the result that can be predicted by the path length difference.

I switched from ntpd to chrony-2.0-pre1. It is a factor of 10 better than ntpd. It does not show the excursions of about 3us that ntpd has (and that are similar to the first derivative of the temperature of the system). The software is now available on my site http://pe1chl.nl.eu.org/

dl1hrc commented 9 years ago

Hi Rob,

thanks for this information. I will reserve more time for your project from now. The time differences are about 1-2us and the jitter 1us on both sites. Next time I will setup the GPS antennas outside to catch more satellites.

I also using this cards on both sites.

Thank you + vy 73s de Adi, DL1HRC

pe1chl commented 9 years ago

Adi, With performance like that you don't need to worry about the ntpd. We had a system that made somewhat larger swings and I decided to try this, and it works well. But it has less options w.r.t. connecting reference clocks, so it may not be worthwile for you to spend time on it to solve that. We now have a system on 70cm as well and while some people observe interference when the CTCSS is switched on, it works fine when CTCSS is off. We are still experimenting with the calibration of the deviation and the timing offset, but of course with the widely spaced locations we use there will always be timing errors due to path length differences. For mobile stations it works fine, but some fixed stations that happen to receive both stations at similar strength and with different path length, there is a problem. Of course, they can solve that with a directional antenna.

dl1hrc commented 9 years ago

Hi Rob, thanks for the answer. I think simulcast is primary interesting for mobile stations driving through a bigger area or in urban environments. As you sad, fixed stations have the possibility in most cases to use a directional antenna or can place them in a shade area of one repeater. Will keep you up to date... 73 Adi

ripice commented 3 years ago

I have now a few remoterx on voters. Id like to test two svxlink repeater on same frequency. It could be done only with ntp or gps sync? Do i need to delay the txs?

pe1chl commented 3 years ago

We have done that, but we used an external program for the tx audio sync that I developed. The program manages the delay to the tx so that they all transmit at the same time (within 20us or so). You need a GPS device that outputs both 1PPS pulses and 10 MHz reference frequency for your TX. The 1PPS pulses are connected to a PC COM port (not USB but a real onbord or on-PCI board serial port) to sync to the 1PPS using chrony.   And an onboard or PCI sound card (no USB). The program can be found on my website in pe1chl.nl/Softw

Rob

On 3/2/21 3:43 AM, ripice wrote:

I have now a few remoterx on voters. Id like to test two svxlink repeater on same frequency. It could be done only with ntp or gps sync? Do i need to delay the txs?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sm0svx/svxlink/issues/85#issuecomment-788532954, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6PHXGYI2SGQZM56JUB2QTTBRGDNANCNFSM4ARCLWOA.

F4ASS commented 1 year ago

Hello all, Happy new year !! ;-) For our project I'm very interested by the pe1chl work. We already have a system based on SM0SVX work for general connection of a batch of relays system in region of Lyon (see ara-r.fr ) I have many MTR2000 VHF relays in spare with 10MHz synchro capability and RSSI calibrated output. For my project I want to test two relays in ISO-Frequency (co-channel) with your audio sampling synchronization system. I have already bought the two BG7TLB GPSDO with 1-PPS en 10MHz signal for testing. I have found pe1chl co-channel.c program but no information about the server structural, client program and pinout use. I would like to gather as much information as possible to start the project... Do you have any information to make this dream a reality ? ;-) Thank you. Sebastien F4ASS

Under you can see the target system for our test :-) image