Synchronisation #3

New issue

Closed

opened 2024-10-14 17:13:40 +02:00 by study-faraphel · 2 comments

study-faraphel commented

2024-10-14 17:13:40 +02:00

Owner

Synchronisation

Les appareils ont pour objectif de jouer parfaitement en même temps le même audio provenant d'un émetteur.

Dû au décalage survenant à cause de la communication sans-fil, il est nécessaire de trouver un mécanisme pour éviter ce problème.

Horloge

Tout d'abord, nous souhaitons parfaitement synchroniser l'horloge des machines pour qu'elles soient capable d'utiliser précisément les mêmes valeurs de temps. Il existe des services permettant cela :

NTP : le protocole classique le plus commun, utilisant un système de serveur / client.
PTP : une alternative à NTP visant à être le plus précis possible.
Chrony : une alternative à NTP semblant plus se focaliser sur une idée de P2P.

Planification

Une fois l'horloge synchronisé, toutes les communications contenant de l'audio devront l'accompagné d'un timestamp, correspondant au moment précis où l'audio devras être joué par la machine.

Ce timestamp est calculé à partir du timestamp actuel, additionné à une valeur de "latence" permettant aux machines les plus en retard de recevoir le packet et de planifier sa lecture au même moment que ceux le recevant plus tôt.
Cette latence pourrait être obtenu à l'aide de ping (par exemple, si la machine la plus lointaine à un décalage maximale de 40ms, nous pourrions utiliser un décalage de 120ms ou de 200ms pour mettre une latence totale minimum, tout en gardant une marge en cas de ralentissement supplémentaire).

Le serveur pourrait continuer de surveiller la latence des autres machines tout au long de son émission pour s'assurer que les machines ne dépasse pas cette nouvelle latence (un noeud intermédiaire s'éteint ralentissant le réseau, channel wifi surchargé, etc...)

# Synchronisation Les appareils ont pour objectif de jouer parfaitement en même temps le même audio provenant d'un émetteur. Dû au décalage survenant à cause de la communication sans-fil, il est nécessaire de trouver un mécanisme pour éviter ce problème. ## Horloge Tout d'abord, nous souhaitons parfaitement synchroniser l'horloge des machines pour qu'elles soient capable d'utiliser précisément les mêmes valeurs de temps. Il existe des services permettant cela : - [NTP](https://fr.wikipedia.org/wiki/Network_Time_Protocol) : le protocole classique le plus commun, utilisant un système de serveur / client. - [PTP](https://fr.wikipedia.org/wiki/Precision_Time_Protocol) : une alternative à NTP visant à être le plus précis possible. - [Chrony](https://chrony-project.org/) : une alternative à NTP semblant plus se focaliser sur une idée de P2P. ## Planification Une fois l'horloge synchronisé, toutes les communications contenant de l'audio devront l'accompagné d'un timestamp, correspondant au moment précis où l'audio devras être joué par la machine. Ce timestamp est calculé à partir du timestamp actuel, additionné à une valeur de "latence" permettant aux machines les plus en retard de recevoir le packet et de planifier sa lecture au même moment que ceux le recevant plus tôt. Cette latence pourrait être obtenu à l'aide de ping (par exemple, si la machine la plus lointaine à un décalage maximale de 40ms, nous pourrions utiliser un décalage de 120ms ou de 200ms pour mettre une latence totale minimum, tout en gardant une marge en cas de ralentissement supplémentaire). Le serveur pourrait continuer de surveiller la latence des autres machines tout au long de son émission pour s'assurer que les machines ne dépasse pas cette nouvelle latence (un noeud intermédiaire s'éteint ralentissant le réseau, channel wifi surchargé, etc...)

study-faraphel added this to the M2-PT-DRP project 2024-10-14 17:13:53 +02:00

study-faraphel commented

2024-10-14 19:43:18 +02:00

Author

Owner

Après quelques tests, nous avons remarqué les choses suivantes :

PTP propose un mode P2P en IPv6 en multicast avec une configuration extrêmement simple, mais le protocole batman fourni un réseau trop rudimentaire pour être utilisable par les implémentations linuxptp & ptpd. (Le réseau batman n'a pas la capacité software-receive, nécéssaire au PTP).
Chrony propose beaucoup de fonctionnalité autour de l'IPv6 et du P2P, mais dans notre cas de diffusion sur le link-local en IPv6, cela ne semble pas pouvoir fonctionner.

Après quelques tests, nous avons remarqué les choses suivantes : - PTP propose un mode P2P en IPv6 en multicast avec une configuration extrêmement simple, mais le protocole batman fourni un réseau trop rudimentaire pour être utilisable par les implémentations [linuxptp](https://www.linuxptp.org/) & [ptpd](https://github.com/ptpd/ptpd). (Le réseau batman n'a pas la capacité `software-receive`, nécéssaire au PTP). - Chrony propose beaucoup de fonctionnalité autour de l'IPv6 et du P2P, mais dans notre cas de diffusion sur le link-local en IPv6, [cela ne semble pas pouvoir fonctionner.](https://serverfault.com/questions/876504/how-to-configure-ntp-server-and-chrony-client-for-time-sync-over-link-local-ipv6)