UGS HC

[maxidcx]

au fait maintenant que le hdmi est reglé pour le multiroom, quelqu'un c'est interresé a Audio over Ethernet avec les modules Dante Brooklin de Audinate.
assez interressant l'idée de brodcaster sur IP en TDM avec une horloge master. C'est du lourd, utilisé dans le monde pro et certaines salles de concert...
le module se pilote en I2C et converti le flux IP en l'I2S. Limite hors sujet mais pusiqu'on est sur un ugs modulaire

[madman]

au fait maintenant que le hdmi est reglé pour le multiroom, quelqu'un c'est interresé a Audio over Ethernet avec les modules Dante Brooklin de Audinate.
assez interressant l'idée de brodcaster sur IP en TDM avec une horloge master. C'est du lourd, utilisé dans le monde pro et certaines salles de concert...
le module se pilote en I2C et converti le flux IP en l'I2S. Limite hors sujet mais pusiqu'on est sur un ugs modulaire

Dante est un protocole mourant, il va bien être remplacé par AVB

De plus, Dante est vraiment orienté Pro alors qu'il y a de nombreuses solutions pour nous Hifiste

[tgrauss]

J'ai regardé la fiche de présentation du module et on dirait qu'ils utilisent aussi un si570 ou équivalent
Le problème est pour se procurer le module. De plus c'est un protocole propriétaire. Je pensais plutôt à un AVR32 couplé avec de la SDRAM, un phy ethernet et de l'USB (j'ai les schémas). Cela offre plus de souplesse car on peut programmer ce que l'on veut (par exemple un protocole de niveau ethernet plutôt que IP permet d'avoir un délai de latence ultra court). On peut de plus capitaliser sur la conception. Un design de ce type permet par exemple soit de concevoir son propre protocole et d'avoir un réseau audio indépendant du réseau ethernet de la maison et d'avoir une 2eme carte identique mais avec un programme différent pour les webradio, décodage mp3, ogg, flac... qui est connectée au réseau ethernet et internet. Ou alors on peut mettre tout sur la même carte et ne pas avoir de réseau séparé entre ethernet standard et le réseau audio.
L'avantage est alors que l'on maitrise à 100% et que l'on fait ce que l'on veut en fonction des besoins.

[Philby]

Dante est un protocole mourant, il va bien être remplacé par AVB

En même temps, le premier post de ce topic est d'octobre 2008, il y a d'autres techno qui seront mourantes d'ici sa conclusion

[maxidcx]

[tgrauss]

J'espère aller plus vite maintenant

Au fait, merci maxidcx pour m'avoir fourni l'email de contact avec la société qui fabrique la carte HDMI ainsi que le manuel de communication avec la carte.

[tgrauss]

J'ai envoyé le paiement pour la carte aujourd'hui.
En fait, je n'ai pas seulement pris la carte, j'ai pris le kit de développement qui contient tout ce qu'il faut pour utiliser la carte sans rien d'autre. Le kit contient aussi des documentations, un écran VFD, l'alimentation... J'ai aussi commandé le câble permettant de reprogrammer le contrôleur
Coût total en comptant les frais de ports et les frais de transfert d'argent western union : 155 euros environ.
Détails :
Frais western union : 15 euros
Frais de port en économique via Federal Express : 77 USD
Câble permettant de reprogrammer le contrôleur : 16 USD
Kit de développement DI35H : 78 USD (la carte DI35H seule ne coûte que 48 USD)

[maxidcx]

Tres prometteur et tres ambitieux !
comme ca tu es sur que ca marche du premier coup.
interressant le VFD, en plus tu dois avoir les codes source dans le package avec un bon example d'application

bon courage pour les essais et le repiquage I2S et surtout partage tes impressions !

[tgrauss]

Je vais réutiliser probablement le VFD dans le projet, comme ca le surcout du kit n'est pas si élevé
Je vais faire des essais et voir si tout marche comme je le pense. Pour le repiquage de l'I2S, les essais ne seront pas avant d'avoir des prototypes fonctionnels pour mon projet. Mais il n'y a pas de risque de problème si la carte fonctionne bien autrement donc le repiquage I2S n'est pas une urgence pour le moment.

[tgrauss]

Je viens de commander 20 SI570 directement chez le fabricant. J'ai put donc préciser la fréquence par défaut lors de la mise sous tension. J'ai choisi 24.576MHz avec un jitter de 0.3ps RMS.
Voir ici http://www.cliftonlaboratories.com/si570_kit_from_k5bcq.htm pour des mesures du SI570
Quand j'aurai les prototype, je vais pouvoir les calibrer. Il faudra que j'achète un oscilloscope, de toute façon ce sera utile pour les différentes mesures et vérifications des prototypes.

Je vais donc inclure en parallèle du cpld un petit micro-controlleur qui va servir à effectuer les calculs de fréquence et à stocker les paramètres de calibration (à moins que je n'inclue qu'une eeprom et que je fasse tout depuis le cpld, à voir en fonction de la difficulté.

Sinon, j'ai avancé sur le VHDL et j'ai codé une partie de l'interface du bus audio et du bus de paramétrage.

[maxidcx]

Salut tgrauss,
j'espere que tu progresses bien
quelque questions concernant le dac, l'horloge et le quartz SI570, notament par rapport à une fifo...

Depuis que j'ai decouvert les bienfaits d'une fifo ca donne envie d'en mettre un peu partout un peu comme des bybee ou de l'eau ecarlate et je dirais meme systematiquement en sortie de receivers SPDIF, meme si on a un asrc just apres, pour eviter que l'asrc transforme le jiter en thd.
Je suis en train de cogiter pour une carte preamp multicanal integrant 3 receivers spdif, une fifo pour le reclock des 3 canaux et un dsp (contenant 2 asrc au cas ou) / l'idée etant de se debarasser des DCX et DEQ et SRC.
Pour la fifo il y a le choix chez Cypress ou IDT depuis 2kx9 jusqu'à 16kx9.
*Quelle est ton opinion sur la "profondeur" de la fifo, en terme de bps ou de sample/secondes ?
sur TOTALDAC, vincent bufferise 10ms... ca me parait beaucoup.

Pour l'horloge de sortie de la fifo, qui pilote aussi les dacs, soit on part sur un quartz programable comme le SI570, soit on ajuste un VCXO avec un DAC ou un R2R bien filtré.
Si on s'inspire de la realisation de apolon34 (ici), il utilise un quarts tentlabs et un DAC7611 (ti 12bits) avec un RC pour le pilotage du quartz.
* Dirais tu que le SI570 sera la meilleur solution en terme de flexibilité mais aussi de performance/jitter ? le probleme c'est d'avoir un faible jitter dans les basses frequences (example ici) et je crois comprendre que le SI est bon surtout dans les hautes...?
Aussi en lisant l'article que tu cites, il y a un temps de stabilization de la frequence qui peux s'apparanter a un jitter...

Concernant les DACs, si je te suis bien tu pars sur le PCM63 qui est un R2R. il y a aussi le PCM1704 dasn cette categorie... aussi je crois comprendre que ces dacs meriten un bon upsampling du fait qu'ils ont une band passante tres elevée. Apolon34 utilise un filtre NPC avec un l'oversampling 8x. qu'en penses tu ?
Enfin je reste sceptique sur l'utilisation d'un double dac, un pour le signal positif, l'autre pour le negatif, en mode balanced, car l'idée du balanced c'est que tout ce qui est comun au 2 signaux sera suprimé parle principe de la soustraction en aval, soit dans l'ampli, soit dans la bobine des HP, hors, en utilisant 2 dac, on peux penser que les defaut issus du dac "positif" existeront ausi dans le dac "negatif" mais juste en oposition de phase. Donc ils s'ajouteront... En plus les dac n'auront pas exactement les memes caracteristique et donc tu va generer une distorsion differenteille ce ce fait. En les mettant en paralelle les dafauts serait reduit de 3db...
voila un post de guido tent qui confirme plus ou moins mon sentiment.
Bien sur cela reste interssant pour le bruit residuel des alims qui ne manquera pas de se trouver sur chaque sortie. celui la sera bien nettoyé.
Dans le DAC audio-gd ref7.1, il y a 4 PCM en paralelle.

le gazon pousse à une sacrée vitesse par ici et chez vous ?

[Tazz28]

Quelle que soit la techno du dac, une sortie "balanced" est toujours meilleure.
- avant même de parler de performances pures d'un dac, sa sortie (que ce soit en courant et a fortiori en tension) va se voir immanquablement polluée par tout un ensemble de bruits en mode commun, même en ayant pris les plus grandes précautions. Une liaison symétrique, au moins jusqu'à l'étage de mise à niveau/buffer de sortie et idéalement sur toute la chaine, permet d'éliminer ce problème.
- une liaison symétrique rajoute 3db de dynamique par nature.
Bien entendu, pour profiter pleinement du symétrique, une chaine full symétrique native comme l'UGS/UP bien connu ici est l'idéal, mais il ne faut pas sous estimer l'intérêt du symétrique même sur une chaine non native (avec systématiquement symétrisation / dé-symétrisation).

Concernant les "défauts" de la sortie "positive" / "négative", elle deviens potentiellement un atout pour réduire les bruits de quantisation de manière statistique. Il faut pas non plus que les deux voies soient complètement disparates. On privilégie cette technique lorsque les deux voies sont dans un même package : utilisation d'un dac single ended stéréo pour faire un balanced mono.
Lorsque l'on commence a chercher la "performance", les dacs intègrent nativement une sortie symétrique ( deux dacs en opposition par voie et en sortie en courant ) et sont configurable en full mono pour mettre en parallèle les deux sorties stéréo. C'est une combinaison des deux.
Le symétrique et la mise en // apportent tous deux des choses en terme de traitement du signal et ne sont pas antinomiques.
La où ça devient intéressant concernant le symétrique (et j'ai d’ailleurs été très très surpris au début) c'est que pour obtenir les performances annoncées, dès que l'on sort du package/boitier on traite le signal en symétrique et après on combine les sorties car elles sont sur des cotés opposés du package et donc ramassent immanquablement du bruits en mode commun (différent) avant de pouvoir êtres combinées de manière différentielle une fois de plus après dé-symétrisation (voir la datasheet et la carte d'évaluation du pcm1794).
De la même manière sur un ES9018 (oui c'est mon dada celui là ) on met en // quatre sorties symétrique en courant par coté de boitier (16 dacs au total) chaque coté a son propre IV et filtre en symétrique puis les deux cotés sont recombinés après dé-symétrisation en une unique voie symétrique (un coté pour le +, un coté pour le -).
Naïvement, j’aurai pensé que que de multiplier les étages de IV et de dé-symétrisation ne ferai que nuire au perfs par rapport à une simple mise en // en sortie de boitier: il en est visiblement rien car vu les niveaux de signaux en jeu, le bruit en MC semble être l'un de nos plus grands ennemis. Je n'ai pu pour l'instant vérifier par moi même cela, mais je fais confiance à TI, ESS et à Russ White qui on fait de vrai tests et mesures à ce sujet.

Par contre pousser le vice aussi loin n'est pas dans la philosophie du projet de tgrauss me semble t il, mais une gestion symétrique a minima en sortie de dac quitte a dé-symétriser ensuite me semble judicieux vu l'environnement "numériquement" perturbé dans lequel il va évoluer.

[tgrauss]

Bonjour,

Je compte mettre une chaine full symétrique en sortie du DAC, c'est la raison pour laquelle je veux sortir en symétrique du DAC.
En ce qui concerne l'horloge, elle va piloter un fifo. Le fifo sera intégré dans la cpld ou fpga si possible. Je compte utiliser un fifo de 100 échantillons par canal (100/192000=0.5ms), mais ce sera à ajuster après tests. En fait la tenue en fréquence du si570 est assez bonne, donc après calibration de l'horloge sur la source, les 2 horloges devraient avoir une fréquence très proche et le besoin d'ajustement de l'horloge devrait être minime. On n'a donc pas besoin d'un gros fifo.
Mais bon, c'est à tester pour s'assurer que l'idée est réaliste.

Dans tous les cas, je vais prévoir des fifo plus gros donc des cpld/fpga un peu plus gros que nécessaire pour pouvoir s'adapter sans refaire les cartes, simplement en augmentant la taille du fifo. En fait, je vais avoir des fifo sur presque chaque carte.
La solution du vcxo et du dac pour piloter est bonne, mais je trouve la solution du si570 plus simple. Mais je n'ai pas testé la solution du vcxo et dac, donc je ne peux pas dire si elle est meilleure ou non.
En tout cas, le si570 peut être ajusté rapidement (0.1ms si je ne me trompe pas) en fréquence pour de petites variations, ce qui est utile quand on veut ajuster car le fifo se remplit ou se vide trop rapidement. Les 10ms sont pour des délais d'ajustement pour de grands changements (par exemple quand il y a un passage de 24.576MHz à 22.5792MHz), donc ce n'est pas un problème.

En ce qui concerne l'environnement "bruyant", j'essaye de le minimiser au plus en utilisant des pcb 4 couches (ground à l'exterieur pour blinder le pcb par exemple), en contrôlant l'impédance des lignes sensibles (ça résuirant en plus le jitter) et en utilisant autant que faire ce peut des régulateurs shunts pour avoir des courants constants dans les bus d'alimentation "grande distance".
Je vais aussi blinder les parties qui sont sensibles et/ou génératrices de bruits EM.

Enfin au niveau des DAC, je vais en réaliser un stéréo avec les PCM63 qui sera inspiré du DAC Spencer D1V33 (hifi de la chambre, connecté sur un clone du F1 de Nelson Pass) et un autre pour le multi-canal inspiré du DAC Spencer FDA-1 et connecté sur des UP.
A terme, une fois le DAC multi-canal fonctionnel, je compte rajouter une carte permettant du filtrage actif des HP pour avoir 2 DAC par enceinte et 2 UP par enceinte (le tweeter étant filtré passivement)

[Tazz28]

Par contre pousser le vice aussi loin n'est pas dans la philosophie du projet de tgrauss me semble t il

Je m'a gouré semble t il

[tgrauss]

Par contre pousser le vice aussi loin n'est pas dans la philosophie du projet de tgrauss me semble t il

Je m'a gouré semble t il

Le but de cette conception est que chacun puisse l'adapter à son besoin. Si le DAC que je vais utiliser ne convient pas, rien n'empêche une autre personne de développer une carte DAC qui réponde à son besoin. La seule contrainte est l'interface au bus audio.
Il y aura un code générique pour le CPLD pour avoir bus audio vers I2S et des registres de contrôle (volume et autre...). Si on n'a pas envie de modifier le VHDL, et qu'il y a un besoin spécifique, il sera toujours possible dans cette carte DAC personnalisée d'utiliser le VHDL générique et un micro-contrôleur qui va récupérer les infos du CPLD et formater pour paramétrer la puce DAC.