Libre-Antenne

OK pour décaler le faisceau, mais le problème est que le plus souvent le délai en IP n'est pas constant, sauf à utiliser du Wifi si cela est possible.
Et cela quels que soient les codecs utilisés sur ADSL ou SDSL

az a écrit:

Entre le studio et l'émetteur A : liaison hertzienne 8,5. (pas de décallage entre le studio et le retour fréquence.

Entre le studio et l'émetteur B : liaison sdsl avec codec Hardware AudioTx. (décallage de plusieurs  secondes entre le studio et le retour fréquence).

Entre la zone A et B, lorsque le RDS passe de l'un à l'autre, les sauts sont pénibles à cause du décallage de temps entre le deux fréquences.

On m'a parlé de plusieurs solution de transport pour diminer le décallage : le barix, et une solution IP sound4, qui ne provoquerait plus de décallage. Je recherche des retours d'expériences.

Il n'y a pas de miracle, avec les liaisons IP, la fiabilité dépend de la qualité du transport ET des buffers permettant de pallier aux variations/ruptures de débits. Plus les accès internet sont fiables, plus les buffers peuvent être réduits.

Avec un FH non compressé, le délai est très court. Pour avoir le même genre de délai en IP, il faudrait travailler également en non-compressé, avec de très petits buffers, et avec des liaisons à temps de transit très courts et parfaitement constant, débits élevé (pour faire du non-compressé) et parfaitement fiable. Si c'est techniquement envisageable, cela n'a, à mon avis, aucun sens d'un point de vue économique.

Pour réduire au minimum le délai de la liaison avec B, tu peux envisager une liaison synchrone du genre de celles proposées par FT en remplacement des anciennes "transfix". Ce sont des liaisons basées sur l'infrastructure ATM de FT, qui permettent (en utilisant la bonne AAL) de réaliser des liaisons à débit et délai constants (les boitiers d'interfaces "LA110" peuvent être utilisés avec les interfaces V11 de certains codecs genre "Hifiscoop LL"). C'est fiable, mais ce n'est pas donné, et cela maintient un léger délai.

Cependant, s'il n'est pas possible de réduire facilement (et pour pas cher) le délai sur la liaison B, il est bien plus facile d'augmenter celui de la liaison A, de façon à ce que les signaux arrivent en même temps sur les différents émetteurs et éviter les "sauts" lorsque les récepteurs passent de l'un à l'autre (ce que font certains réseaux pour retarder le signal diffusé depuis la TE). Exemple de machine à mettre sur ta liaison A:

http://www.sonifex.co.uk/redbox/rbds2_ld.shtml

http://www.tcelectronic.com/d22-features.asp  (5 secondes maxi, ce genre de truc est généralement utilisé pour resynchroniser le son avec l'image en TV)

http://www.bswusa.com/Profanity-and-Pro … 0-P74.aspx (il s'agit à la base d'un "profanity delay", c-à-d un appareil permettant de "couper" un instant du signal en cas de dérapage dans une libre-antenne par exemple, mais ça peut aussi servir comme simple retard).

Évidement, il faut oublier le retour tuner en studio si tu retardes ta liaison A...

Pour un grand nombre de raisons liées à la nature même du réseau Internet, le temps de passage des paquets de données est très variable. Ce n'est pas fait pour les applications temps réel. Pour cette raison l'on doit employer des buffers importants si l'on ne veut pas de coupures pour cause de paquets arrivés trop tard ou en désordre. Comme ce n'est pas vous qui gérez les buffers, la solution que vous cherchez est assez compliquée. Elle consiste, comme le dit elecman, en l'adjonction d'un buffer supplémentaire pour le signal FH. Cependant, comme le retard IP est variable, il faut pouvoir gérer la compensation automatiquement au moyen d'un retour et marquage inaudible du programme. Autant le dire tout de suite - une usine à gaz, sauf à observer, avec de la chance, qu'un buffer à valeur constante améliore sensiblement les choses quant à la commutation RDS.
Vous pouvez toujours essayer en empruntant du matériel. Sinon et si vous le pouvez, pensez à un autre FH. C'est toujours la meilleure solution de transport.

Dernière modification par BB (12-01-2012 17:58:32)

BB a écrit:

Grouik a écrit:

Avec un FH non compressé, le délai est très court. Pour avoir le même genre de délai en IP, il faudrait travailler également en non-compressé, avec de très petits buffers, et avec des liaisons à temps de transit très courts et parfaitement constant, débits élevé (pour faire du non-compressé) et parfaitement fiable. Si c'est techniquement envisageable, cela n'a, à mon avis, aucun sens d'un point de vue économique.

Ce n'est, tout simplement, pas faisable. Tout ce que fait un FH en matière de codage non compressé, vous êtes, de toute façon, obligé de la faire, quelle que soit votre solution alternative numérique. Et il n'y a pas plus vite que la ligne droite dans l'air et sans aucun stockage intermédiaire (sauf dans l'espace, où il n'y a même pas d'air ).

Quand je dis "du même ordre", c'est évidement dans un contexte de changement automatique de fréquence par un récepteur RDS, ou l'on peut tolérer des écarts de plusieurs dizaines de ms. Avec une infrastructure du genre VPN sur réseau dédié + fibre jusqu'aux équipements terminaux, on peut maintenir des délais très courts (donc qui s'apparentent plus aux délais courts des FH ou LS qu'aux longues secondes des systèmes de streaming via de l'Internet "normal"), à condition de tomber sur un opérateur télécom performant. D'autant que certains FH numériques, même s'ils sont non-compressés, ont du délai (mécanismes de multiplexage des canaux audio + datas + systèmes de correction d'erreur et de synchronisation). Mais économiquement cela n'aurait vraiment aucun sens.

BB a écrit:

Grouik a écrit:

Pour réduire au minimum le délai de la liaison avec B, tu peux envisager une liaison synchrone du genre de celles proposées par FT en remplacement des anciennes "transfix". Ce sont des liaisons basées sur l'infrastructure ATM de FT, qui permettent (en utilisant la bonne AAL) de réaliser des liaisons à débit et délai constants (les boitiers d'interfaces "LA110" peuvent être utilisés avec les interfaces V11 de certains codecs genre "Hifiscoop LL"). C'est fiable, mais ce n'est pas donné, et cela maintient un léger délai.

Toute solution par commutation de paquets et utilisant Internet est nécessairement sujette à retards plus ou moins importants et variables.

ATM est une couche plus basse qu'IP. Cela peut servir à transporter de l'IP, mais ce n'est pas le seul usage. ATM a été conçu pour faire de la voix, de la vidéo, des données, avec différents modes de fonctionnement (AAL) selon le type d'usage souhaité. Les cellules ATM sont courtes et de taille constante, ce qui permet un transit rapide. Avec une infrastructure ATM bien configurée, le délai peut être suffisamment constant pour les applications audio courantes. Les horloges reconstituées par les équipements terminaux sont largement assez stables pour faire fonctionner des codecs audio (sans autres buffers que ceux nécessaires au fonctionnement des algorithmes de compression et décompression).

BB a écrit:

Toute solution numérique par ligne dédiée subit aussi un retard dont la valeur n'est pas connue et garantie - essayez d'obtenir des engagements de FT là-dessus pour en avoir le coeur net, si vous voulez. Je n'ai jamais pu, pour ma part, quand j'en ai eu besoin pour une application de diffusion synchrone.

Si le retard n'est ni connu ni garanti, il peut cependant être assez constant avec des infrastructures ATM. J'utilise des liaisons de ce genre, et je n'ai pas mesuré de variations de délai significatives depuis qu'elles ont été mises en service. Cependant, si c'est bien plus fiable et présente beaucoup moins de délai qu'une liaison via Internet, c'est aussi plus cher...

Le cas de la diffusion synchrone est un cas extrême qui ne concerne pas grand monde...

BB a écrit:

Cependant, l'on n'a pas besoin de tant de précision (*) dans le cas d'espèce et il pourrait y avoir une solution dans ce sens, si la liaison FH est impossible. Côte prix, il n'est pas évident que la location d'une ligne dédiée soit moins chère qu'un FH.

Dans le cas exposé au début de ce fil de discussion, un FH est utilisé pour le premier site, et on peut supposer que la radio en aurait fait de même pour le second si cela avait été simple... Mais quelque chose me dit que l'autre site est un peu plus loin, et peut être moins "visible"...