Désolé pour la longueur de cette réponse - elle représente plusieurs semaines de recherche par essais et erreurs. Je crains que les détails n'importe donc j'en ai fourni plus plutôt que moins. C'est axé sur le partage audio
Comme d'autres sur ce fil, j'ai été intéressé par la distribution audio synchronisée dans toute la maison avec des espaces où les environnements acoustiques se chevauchent. Comme le son se déplace à environ un pied/millisecond, cela nécessite une synchronisation au niveau d'environ 10 millisecondes. J'ai trouvé un moyen de le faire fonctionner avec VLC et de le maintenir synchronisé pendant des heures sans déraper. Bien que j'admets avoir regardé le code source de VLC pour essayer de comprendre quels horloges sont utilisées, je ne prétends pas comprendre ce qui se passe là-bas. De plus, une grande partie de ce que j'ai fait a été empirique. Ainsi, si les personnes qui comprennent vraiment VLC offrent des éclaircissements sur une meilleure façon de le faire, je suis très receptif. Avec ces mises en garde formulées, voici ce que j'ai fait qui semble fonctionner.
Configuration
J'ai quatre zones où je voudrais partager l'audio et une collection d'ordinateurs de différentes générations que je suis prêt à consacrer pour fournir l'audio. Certains de ces machines fonctionnent sous Linux (Ubuntu 12.04) tandis que d'autres fonctionnent sous Windows. Dans l'ensemble, il était plus facile de synchroniser les boîtes Linux que les boîtes Windows, mais c'était possible.
Sur les boîtes Linux, il était nécessaire de mettre à jour les pilotes pulseaudio en utilisant ppa:ubuntu-audio-dev/ppa pour obtenir la version à faible latence. Sinon, la configuration était standard. VLC se plaignait de la latence sans cette mise à jour. J'espère que lorsque nous obtenons le 14.04 ce problème disparaîtra.
Sur les boîtes Windows, je cours Windows 7 Pro.
L'audio est servi à partir de VLC un boîtier Linux qui est indépendant des machines de lecture. Il est juste en aval du pare-feu où le réseau entre dans la maison.
Le réseau est un mélange de câblé gigabit et sans fil (802.11g).
Choses qui peuvent ne pas importer
Parce que je suis un maniaque du temps, toutes les machines sont verrouillées ensemble en temps au niveau sub-millisecondes en utilisant NTP. Sur les boîtes Linux, c'est trivial. Sur la boîte Windows, j'utilise l'implémentation Meinberg de ntp (trouvé à http://www.meinbergglobal.com/english/sw/ntp.htm) La boîte qui sert l'audio est synchronisée avec les horloges externes normales. Cependant, les machines de lecture ont leur temps synchronisé exclusivement avec le serveur audio et le suivent de près. La ligne du fichier ntp.config sur les machines de lecture qui fait cela est
serveur 10.17.0.12 iburst burst minpoll 4 maxpoll 4 prefer
Cela garantit que les vérifications de temps sont effectuées toutes les 16 secondes - clairement je ne suis pas concerné par le trafic réseau.
Serveur
Le serveur est configuré pour surveiller le flux PulseAudio afin que tout ce que je joue sur le serveur soit renvoyé au flux de sortie.
Le flux de sortie est un flux rtsp servant deux canaux à 44.1kHz. Encore une fois, il y a probablement des choses que je pourrais faire pour conserver la bande passante, mais je suis plus intéressé à obtenir la synchronisation correcte qu'à minimiser la bande passante.
Dans les Préférences (sous Outils)
-
Dans les paramètres simples, Audio - assurez-vous que l'audio Time-Stretching est activé
Pour le reste des paramètres, cliquez sur "Tout" en bas de la page des Préférences
-
Permettre la priorité en temps réel
-
Synchronisation du réseau - Cochez la case Horloge maitresse du réseau et fournissez l'IP du serveur Maître (cette machine dans mon cas)
-
Audio - activer le rééchantillonnage audio de haute qualité et cocher Activer l'audio de time-stretching
-
Entrée/Codecs - celui-ci semble être le plus important - faites défiler jusqu'en bas de la page
- Définir le cache réseau sur 300ms - vous devrez peut-être le varier en fonction de la vitesse et de la contention de vos machines - sur les miennes 300 suffit
- Compteur de référence d'horloge moyen - j'ai trouvé que 1000 fonctionnait bien - cela semble affecter à quelle vitesse la synchronisation suit de petits changements dans le temps
- Activer la synchronisation de l'horloge
- Clock jitter - 30ms fonctionne sur mes systèmes
- Cochez la Synchronisation du réseau
- J'ai fourni des noms de fichiers pour le répertoire d'enregistrement et le répertoire Timeshift - je ne sais pas si cela importe
- Granularité de Timeshift - je l'ai réglé sur 1000, encore une fois, je ne suis pas sûr que cela ait de l'importance.
Clients
Configurez les clients pour lire le flux fourni par votre serveur.
Les clients sont configurés pour correspondre au maître avec quelques exceptions - ici je vais lister juste les différences
Windows - Préférences
- Augmenter la priorité du processus
- Définir la source d'horloge sur l'heure du Système (Dangereux!) - j'ai essayé les autres réglages et ils ont tendance à dériver. Cela semble bien fonctionner tant que le NTP fait son travail. Quand j'arrête NTP, les choses commencent à dériver. En regardant le code source, il semble que cette option utilise
GetSystemTimePreciseAsFileTime()
- sur les systèmes modernes c'est un minuteur sub-microseconde et c'est apparemment l'horloge que NTP gère. Je suis sûr qu'il y a une raison pour laquelle c'est marqué comme dangereux donc utilisez-le à vos risques et périls - cela semble fonctionner pour moi.
- Dans la Synchronisation du réseau - Ne cochez pas l'Horloge maitresse du réseau (c'est la cliente après tout) Fournissez l'IP de votre horloge maitresse.
Autrement, tout est pareil que sur le maître.
Linux -
Préférences
- Vous n'avez pas le choix sur l'horloge - vous devez fournir l'IP du maître tout comme vous le faites pour Windows.
Mises en garde
Ayant dit tout cela, tous les clients Linux que j'ai installés semblent bien fonctionner - même un ancien netbook avec très peu de puissance.
Windows est une autre histoire. J'ai essayé deux boîtes, toutes deux avec des processeurs i7 - elles sont relativement récentes et rapides. Une, un ordinateur portable Lenovo, fonctionne avec la recette ci-dessus. L'autre, un boîtier Shuttle, a fonctionné jusqu'à un certain point mais après quelques heures commençait à dériver. J'ai finalement abandonné et l'ai configuré en dual boot avec Ubuntu. Une fois que j'ai fait cela, tout a juste fonctionné. Bien que je sois convaincu que Windows peut être fait pour fonctionner puisque j'ai une preuve d'existence, Linux semble être plus proche d'une solution fiable. J'ai maintenant trois boîtes avec le client Linux et ils fonctionnent tous parfaitement et restent synchronisés sur des échelles de temps de nombreuses heures sans avoir besoin de redémarrer le client VLC.