Libre-Antenne

BB a écrit:

Bon, nous n'allons quand même pas nous étriper pour une question d'horloge!
Si vous y tenez tant que ça, je vais vous laisser un  os:
Si l'horloge en question n'est pas bonne et est utilisée par un abruti, elle peut nuire à la qualité. Si elle est utilisée comme il faut, elle ne l'affectera pas.
C'est bon comme ça?

C'est assez tentant comme conclusion, je l'avoue, mais un peu condescendant quand même, non ? Avant de conclure que quelqu'un est un abruti, je préfère connaitre les éventuelles contraintes, qu'elles soient techniques ou financières.

BB a écrit:

Cela me surprend un peu et même plus, de lire ce que vous écrivez. Ne me dites pas que vous ignorez le principe de base des transmissions numériques qui veut que le récepteur, sauf réalisations très spécifiques et minoritaires, doit pouvoir se synchroniser sur le flux de données uniquement.

Je n'ignore évidement pas cela. Mais tout n'est qu'affaire de compromis. On ne parle pas d'une transmission numérique juste pour transmettre des données, mais du son, ce qui introduit des contraintes supplémentaires, qu'il est possible de gérer de plusieurs manières différentes: certaines sont bonnes, et d'autres moins bonnes. Et d'un point de vue concret, ce ne sont pas toujours les plus judicieuses qui sont utilisées (peu importent les bonnes raisons ou les prétextes), même si on peut le regretter. Si l'on y ajoute une contrainte de délai et des contraintes en terme de qualité de son, cela complique un peu la problématique (qui d'un strict point de vue "données" reste assez simple, je vous l'accorde).

BB a écrit:

La partie réception se synchronise automatiquement à la vitesse d'arrivée des données et donc à la vitesse de l'encodeur (puisque nous étions d'accord que ce dernier devrait pouvoir se synchroniser avec le réseau FT, et puisque la fréquence nominale d'échantillonnage nous est connue). Le fait d'avoir une horloge à l'arrivée est tout bêtement une facilité pour certaines applications. Comme je l'ai dit, l'on pourrait s'en passer assez facilement et, en tout cas, je ne vois pas de raison valable de l'utiliser pour un CNA brute de décoffrage. Elle peut, en revanche aider à ramener la référence locale à la fréquence exacte un peu plus facilement.
D'autre part, je ne vois pas la nécessité de changer la fréquence d'échantillonnage (SRC) pour une simple transmission audio, mais là nous nous égarons...

Vous n'avez pas saisi mon propos. Pas grave.

Par changer la fréquence d'échantillonnage, je parle de passer, par exemple, du 48.004KHz de l'encodeur (lié à un quartz que vous qualifiez vous-même de "cochonneries")  au 47.991 du décodeur (autre "cochonnerie"), dans le cas, existant, ou la vitesse de lecture serait fixe et déterminée par la carte son à l'arrivée (cas du streaming internet, évidement, pas des liaisons synchrones avec codecs entièrement synchronisés sur le réseau).

BB a écrit:

C'est marrant cette obsession chez vous! Si vous êtes d'accord avec moi, les gros buffers ne servent pas à égaliser les fréquences, mais à gérer la livraison des paquets avec des retards variables et en désordre. S'il n'y a pas de rupture de flux, l'effet de fréquences différentes d'encodage/décodage, vu que celle-ci est de l'ordre de la précision des quartz n'a pas plus d'importance [...]

Tout dépend de la méthode utilisée par le décodeur.

Si celui-ci décode en se basant sur le quartz de sa carte son, je serais d'accord avec vous s'il s'agissait de lire un flux pendant quelques heures, comme c'est généralement le cas lorsque quelqu'un écoute un flux sur son ordinateur. L'écart de fréquence entre les parties audio de l'encodage et du décodage seraient assez insignifiantes, et le délai initial (pré-remplissage du buffer au démarrage) se réduirait ou augmenterait trop lentement pour que cela pose problème sur la durée d'utilisation. Il s'agit de cas existants dans lesquels la capacité du décodeur à s'adapter à ce qu'il reçoit est limitée, même si cela va à l'encontre de certains principes, et lorsque la limite est atteinte, cela provoque soit une purge du trop plein du buffer, soit une coupure en attendant un re-remplissage.

Si, à l'inverse, le décodeur s'ajuste sur ce qui rentre, on tombe dans une problématique de taille de buffers, celle-ci déterminant la vitesse à laquelle le décodeur va devoir s'ajuster aux données qui arrivent.

BB a écrit:

que le fait d'acheter un CD ou un 33 tours et de l'écouter avec votre lecteur qui lit forcément à une vitesse différente de celle de l'enregistrement si l'on y regarde de plus près.

Stabilité Vs. Précision (cf. plus bas)... Si l'on y regarde de plus près, on s’aperçoit que l'inertie de la platine qui lit votre 33 tours est déterminante pour la stabilité (à l'échelle de l'audible) de la lecture. Comme peut l'être celle des mécanismes de régulation de débit dans un système numérique.

BB a écrit:

Idem pour toutes les machines basées sur des PCs qui ont des quartz que nous, en radio et télécom appelons "des cochonneries". Il est vrai que ces applications, à mon avis, ne méritent pas plus, car bien malin qui pourra détecter une différence de vitesse de 200 ppm, 0,09 Hz pour un LA(3), sachant que le LA# est à +26 Hz et le SOL# à -25 Hz environ. Une telle oreille absolue mériterait d'être inscrite au patrimoine de l'humanité. Tous les autres peuvent écouter les disques et les fichiers audio problème

La précision et la stabilité sont deux critères différents. Un LA(3) stable, même avec une légère imprécision, est (à mon humble avis) préférable à un LA(3) qui fluctue, même si sa valeur moyenne est parfaite.

BB a écrit:

Grouik a écrit:

Mais à priori, je n'avais pas tant de raisons d'avoir une confiance aveugle dans les horloges reconstituées indépendamment à chaque extrémité par des petits boitiers en plastique qui coutent moins cher qu'un bon lecteur de CD.

Si même vous vous mettez à utiliser maintenant des boîtiers en plastique à 4 sous, au lieu d'acheter des interfaces chez qui vous savez, c'est vraiment la fin du monde!

Je ne choisi pas les équipements terminaux des opérateurs de télécom. En l’occurrence, pour les liaisons ATM, les LA110 (RAD) me sont imposés. Mais comme ça marche bien pour l'application que j'en fais, on ne va pas se plaindre...

C'est qui "qui vous savez" ??

Grouik a écrit:

C'est assez tentant comme conclusion, je l'avoue, mais un peu condescendant quand même, non ? Avant de conclure que quelqu'un est un abruti, je préfère connaitre les éventuelles contraintes, qu'elles soient techniques ou financières.

Mais non, voyons! Je suis tout simplement conciliant. Je ne peux pas mieux faire, vu que je suis essentiellement en désaccord sur la question et je ne puis vous donner raison. Je cherche donc un compromis.
Quant à l'abruti hypothétique, c'est celui qui, selon le principe de Peter, se serait cru de taille à développer un produit dont il ne comprend pas le fonctionnement. Simple construction, personne en particulier.

Grouik a écrit:

......
Vous n'avez pas saisi mon propos. Pas grave.

Non, je n'y arrive pas. Si quelqu'un d'autre a compris, la discussion est ouverte.

Grouik a écrit:

Par changer la fréquence d'échantillonnage, je parle de passer, par exemple, du 48.004KHz de l'encodeur (lié à un quartz que vous qualifiez vous-même de "cochonneries")  au 47.991 du décodeur (autre "cochonnerie"), dans le cas, existant, ou la vitesse de lecture serait fixe et déterminée par la carte son à l'arrivée (cas du streaming internet, évidement, pas des liaisons synchrones avec codecs entièrement synchronisés sur le réseau).

Ben, il ne se passera rien de particulier, puisque la carte son, vivant au rythme d'une horloge générée sur place n'est pas plus qualifiée pour dire ce qui est vrai en matière de base de temps que l'encodeur ci-dessus. Si vous avez deux PCs, ils lisent forcément à des vitesses différentes, car il n'y a aucune synchronisation de leurs horloges et la transmission n'est pas synchrone, donc aucune référence commune. Pourquoi est-il si difficile de comprendre cela, c'est moi qui ne comprends pas cette fois-ci!
Et cela ne gêne personne, tant que l'on ne commence pas à faire des sommes et des différences des signaux respectifs obtenus....

Grouik a écrit:

Stabilité Vs. Précision (cf. plus bas)... Si l'on y regarde de plus près, on s’aperçoit que l'inertie de la platine qui lit votre 33 tours est déterminante pour la stabilité (à l'échelle de l'audible) de la lecture. Comme peut l'être celle des mécanismes de régulation de débit dans un système numérique.

Dans les deux cas de figure, je vous fiche mon billet que si tant est que l'enregistrement s'est fait à 33,3333 tr/min, la lecture ne se fait pas à la même vitesse et la différence est au moins du même ordre que la précision d'un quartz type "cochonnerie".

Grouik a écrit:

La précision et la stabilité sont deux critères différents. Un LA(3) stable, même avec une légère imprécision, est (à mon humble avis) préférable à un LA(3) qui fluctue, même si sa valeur moyenne est parfaite.

On va finir par tout mélanger. Un quartz, même mauvais,  qui n'est pas en panne
ne fait pas de sauts ni des variations. La preuve, les pianos numériques. Ils n'ont pas, à ma connaissance, de bases de temps extraordinaires. Juste ce qu'il faut.

Grouik a écrit:

....
Je ne choisis pas les équipements terminaux des opérateurs de télécom. En l’occurrence, pour les liaisons ATM, les LA110 (RAD) me sont imposés. Mais comme ça marche bien pour l'application que j'en fais, on ne va pas se plaindre...

Et c'est tant mieux.

Grouik a écrit:

C'est qui "qui vous savez" ??

Mais, moi, évidemment, qui d'autre! .

Dernière modification par BB (18-01-2012 02:13:41)

Grouik a écrit:

Je ne parle pas de deux PC qui lisent à des vitesses différentes chacun dans son coin, mais d'un PC qui doit lire ce qu'encode l'autre... ni trop vite, ni trop lentement...

Je vois votre raisonnement et il convient de l'évaluer au vu des éléments suivants:
1. Si vous transmettez de manière synchrone, il est clair que les deux extrémités peuvent facilement aller à la même vitesse.
2. Si vous transmettez en asynchrone, il est possible de résoudre le problème de plusieurs manières, sans perte d'information, par exemple au moyen d'un FIFO avec action de celui-ci sur l'horloge de lecture. Donc, en dernier ressort, d'une variation de vitesse de votre 33 tours de 200 ppm avec des quartz achetés aux puces et de, mettons, 20 ppm avec des quartz un peu meilleurs, mais tout à fait abordables.
Si vous synchronisez avec une référence commune (GPS, FI, DCF77) se sera théoriquement 0 et la question revient: qui peut faire la différence entre 20 ppm et 0 ppm? (*)
3. Si vous utilisez IP, le problème est le même, sauf que les bufferts sont déterminés par d'autres contraintes et l'identité des fréquences n'y changera rien.

Grouik a écrit:

On ne mélange rien, simplement dans cette discussion, vous me parlez de précision, alors que je parle des éventuelles fluctuation d'une horloge reconstituée (autour d'une valeur moyenne) et de mécanismes permettant de lire un flux continu. Évidement qu'un quartz que vous qualifiez de "cochonnerie" est largement suffisant pour la plupart des applications audio, on est totalement d'accord sur ce point, mais ce n'est pas le sujet.

Il ne m'a pas semblé utile d'entrer dans ces détails, car dans le cas de figure l'effet est exactement le même. Il s'agit d'une différence des fréquences causée soit par l'imprécision du calage du quartz, soit par l'instabilité en température, soit encore par le vieillissement , en fait par les trois facteurs réunis. La variation de cette différence est très lente et n'a pratiquement pas d'incidence sur la "fluctuation de la vitesse du 33 tours" qui dépend essentiellement du module de la différence et de la taille du FIFO (+ quelques autres détails relatifs à l'asservissement).

Grouik a écrit:

Dans le cas qui nous intéresse, si on synchronise chaque bout de la liaison sur son propre quartz, ça va soit finir vide, soit déborder, à moins d'avoir une chance assez improbable...

Dialogue de sourds tout ça...

Voir explication plus haut (2.).
(*) Au fait, avez-vous pensé à calculer ce qui se passe quand vous tournez lentement la tête (10 cm/s) en écoutant une note soutenue? Cela fait dans les 450-460 ppm entre les deux oreilles.

Dernière modification par BB (18-01-2012 11:02:54)

Grouik a écrit:

...
2 - C'est exactement ce que j'ai dit dans plusieurs messages précédent: il doit y avoir un mécanisme qui, partant du remplissage d'un buffer, joue sur la vitesse de lecture. Toute la question est de savoir comment on joue sur cette vitesse:

- asservissement d'une horloge avec une certaine "inertie" pour que cela soit inaudible, ce qui présente l'avantage de rester "synchrone",
- solution de facilité, utiliser du "hardware" basique, et rendre le système "asynchrone" via un bout de logiciel qui jouera un rôle de SRC, avec des risques de dégradation de qualité.

Ce n'était qu'un exemple (parmi d'autres) confirmant mes déclarations de principe. Je n'entre pas dans les détails technologiques pour l'instant. Si l'on parle de réalisation concrète et de ses défauts, c'est une autre affaire, mais dans ce cas, elle m'échappe complètement, car tout est déjà fait.

Grouik a écrit:

...
Et c'est aussi pour cela que j'avais évoqué la possibilité d'améliorer via GPS (message #19) les systèmes qui ne sont pas capables de se synchroniser sur le réseau. C'est réalisable en utilisant de chaque coté des cartes son capables de se synchroniser sur un wordclock, et d'avoir à chaque bout un générateur de wordclock synchronisé sur GPS. Ça se trouve mais c'est un peu cher, tout ça...

Je n'ai pas d'opinion sur du matériel que je ne connais pas. Vous avez sûrement raison.

Grouik a écrit:

3 - On est d'accord sur le fait que les buffers servent à la fiabilité de la transmission. Mais l'identité des fréquences reste un critère d'un point de vue audio. Même avec des buffers importants, un débit à peu près stable, des mécanismes en TCP assez efficaces pour maintenir le remplissage du buffer de réception, le point N°2 reste vrai (il faut décoder le son à l'arrivée à la vitesse à laquelle il est encodé à l'autre extrémité).

Pour éviter de tourner en rond, avez-vous le souvenir de la solution vidéo pour la diffusion des films à la TV (j'ignore si l'on le fait encore)? On les passait à 25 images par seconde au lieu de 24. En supposant, postulat de base non contesté, une différence faible (200 ppm ou moins), je ne vois pas d'autre raison que celle de ne pas perdre de données pertinentes avec un buffer de taille "raisonnable". Par exemple, je peux vous proposer une solution qui consiste à lire à une vitesse de 200 ppm inférieure à la nominale, ce qui ne se verra pas (vous êtes d'accord?) et que l'on accélère graduellement au besoin, en fonction de l'état du buffer, que l'on connaît par la valeur des pointeurs. Je ne suis pas spécialiste de l'informatique intime des PCs. J'ai néanmoins la conviction qu'une solution purement software est possible, puisqu'elle est très facile sur un DSP.
SRC est bien grand mot pour ce genre de dispositifs et il n'y a pas de calculs sur les échantillons. Simple petite variation de vitesse.
Pour être tout à fait conciliant, je dirai que l'on obtient une espèce de synchronisme quelque peu imparfait, mais suffisant, en se basant non sur une référence de temps commune, mais sur l'état d'un buffer côté réception.

Grouik a écrit:

BB a écrit:

...
La variation de cette différence est très lente et n'a pratiquement pas d'incidence sur la "fluctuation de la vitesse du 33 tours" qui dépend essentiellement du module de la différence et de la taille du FIFO (+ quelques autres détails relatifs à l'asservissement).

A propos de ceux-ci:
Au fond, ce n'est pas grand-chose. Il faut récupérer les flags du FIFO, effectuer quelques fonctions logiques élémentaires, filtrer passe-bas et mettre une varicap sur le quartz en modifiant éventuellement les condensateurs qui y sont déjà. Je passe sur les détails des détails - constantes de temps et autres amortissements.

Grouik a écrit:

Dans le cas d'un quartz, on est d'accord.

Mais dans le cas d'un système reconstituant une horloge à partir d'un train de données, sur un équipement réseau, rien ne garantit, à priori, que l'on soit meilleur qu'un mauvais quartz, puisque dans un contexte "données", il suffit que les données et les horloges soient synchrones (vous l'aviez d'ailleurs rappelé). En fait, tout réside, amha,  dans ce que vous appelez "détails relatifs à l'asservissement"...

Comme j'ai aussi dit (quand vous indiquiez que les horloges fournies par les interfaces ATM étaient bonnes ) qu'il valait mieux, quelles qu'elles soient, ne pas les utiliser telles quelles, mais s'en servir de référence pour synchroniser la base de temps locale. Comme vous le savez, je n'en doute pas, un quartz très moyen est assez bon en matière de bruit de phase. Ce que lui manque c'est une précision de calage et une stabilité long terme (température, vieillissement), laquelle se trouve précisément au niveau de l'horloge de l'interface.
Je n'ose pas imaginer que vous ignoriez le fait que si vous remplacez le quartz d'un synthé par un géné modulé en fréquence,  ça marche quand même. C'est le même principe.

Dernière modification par BB (18-01-2012 16:58:36)

moi a écrit:

Quelqu'un connait un bon thérapeute spécialisé dans les problèmes de couple ?

Comme vous y allez! L'on se connaît à peine. Même pas un an .