Parlons svp , un peu Wookie ….
pour débattre du Wi-Fi extension de l’ethernet 8o2.3. , et de ses contraintes dans un usage audio ‘ sans compromis .’ …???
L’objectif n’est il pas SVP,
de contenir au mieux la récurrence temporelle du flux isochrone , à bande passante garantie, et à débits défini et constant : qu’il soit 8o2.3 filaire aérien , USB audio 2.o , ou encore PCM/Psd/Dop-Dsd pour le spdif  ( tos/coax.75) ou AES sa version symétrique +/_ (xlr. 11o) ou inter chip I2S. en LVDS ( différentiel +/- low voltage + 5.o V.DC.Rj/Hdmi. ).(l’I2s. divise en quatre signaux  : horloge bit et word + data . ces signaux sont très sensibles et destinés à la comm. interchip soit . ‘Dac bus hardware.’ . Ce format standard  ( non normé) a l’avantage de dissocier data et clocking . Ce qui permet un traitement une optimisation du clocking indépendamment. des autres signaux. 
En signal différentiel +\_ le I2s peut être transporté sur de très courtes distances via hdmi ou rj. c’est le lvds. (Low Voltage differenentiel Signal) Et dans. ce cas communiquer avec le Dac en bas niveau OSI. et supprimer  traitement, process du DIR. Digital interface receiver , typiquement assurer en puce moderne : Ak4118 , ou du NOS cs  ou Wolfson exemples)
Pour le 8o2.3  (le réseau Ethernet) Avec 'Latence' ms-1, 'Delay' ms-1, 'Over all packet latency' en % n’est il pas possible, (Paquet loss est aussi une information de Qualité ) .. SVP d’évaluer  le 'Networking jitter' ???
qui se composerait du 'Jitter constant': valeur consolidé moyenne de la variation de 'Delay' paquet à paquet  ; 
et le 'Jitter dit transitoire' qui affecterait un seul paquet,  égal aussi à 'la variation de delay à court terme' ; et aurait pour causse essentielle la congestion des paquets ... 
( pour rappel…la norme de qualité , pour le 8o2.3 est  : 
de 2o à 3o nano seconde 1o-9 S-1 pour le delay,  
1% de 'paquet loss', 
et +/-15o milli seconde 1o-3 S-1 pour le 'over all packet latence'. ) 
* Ces valeurs ne pourrait être obtenue avec une infrastructure Wi-Fi  (fussent elles a/b/c/g/n af-.ay….mesh…) .?, et bien sûr qu’il ne faudrait pas confondre avec les aptitudes au débit ?
* Ces valeurs , avec aussi la norme G711 (aes/67 …) ( notamment pour la Voip voix sous ip. Pour une analogie avec le flux audio ) avec le MOS score de compréhension d’une conversion sur flux ip de 1 à 5 (anecdotique…)). Permettraient aussi l’évaluation qualitative de l’infrastructure ?. Et du respect de l’integrite temporelle du flux isochrone pour les infrastructures ip. (Pas de Voip sous wifi…!)
Ainsi avec ou Sans travail sur la couche protocole IP : trunk ip. , Qos., 8o2.Ii …et administration L2/L3 pour la gestion , et prioriterisation des en-têtes UDP/(ip) , il serait possible de déployer at home des stratégies d’optimisation de l’infrastructure Ip. : qualité des câbles , chasse aux interférences EMi-HF .  : Fibre optique FO et cage SFP+, SFP-gbic , des courants de fuite , isolation et gestion des masses , et même un reclocking low phase noise OCXO. des trames IP.  Permettrait de contenir le networking jitter et garantir très probablement une meilleure qualité temporelle du flux ip numérique isochrone.? Ces stratégies se présenteraient comme impossible avec le Wi-Fi ‘
Pour les flux numérique usb , spdif ,..cela serait peut être la fonction d’un pc. d’un lecteur réseau : de distribuer un flux informatique , et éventuellement d’opérer une conversion de protocole , et un déplacement de couches ‘OSÎ’ ; extractions des échantillons à partir des paquets Ip. …)
Un bon lecteur réseau s’efforcerait alors d’opérer de façon optimal cette fonction : le respect de l’intégrité des paquets ip.  , au delà de la robustesse 8o2.3 et le respects du flux isochrone  : le flux informatique à récurrence temporelle stricte , idéalement à guigue nulle pour le flux des échantillons sur usb spdif …. (Fameuse cette guigue ou jitter serait le delta de temps dans la distribution des echantilllons numériques, caractériser par délay et latence , mesurer en temps . soit la
précision temporellle à court terme , cf. Bruit de phase , et Allan Variance qui  pourrait aussi s’exprimer en  Temps .TAU S-1 ( de la pico seconde 1o-12 jusqu’à la dizaine centaine de Femto seconde 1o-15 )
Puis L’autre partie de la fonction serait la conversion de protocole , accompagné souvent d’un changement de couche OSI ? : N’est ce pas un process informatique ?
(A l’exemple de la conversion d’un flux réseaux 8o2.3 rj vers l’USB 2.o audio ). Ce process consommerait du temps CPU. et pourrait aussi altéré l’échantillon par perte d’information , mais en fonction de la performance de l’algorithme de conversion et sa consommation en temps introduire ou non logiquement delay et latence corrélé au temps et donc à la performance CPU. ou du code associé….
De plus ces protocoles ne seraient pas dotés de correction d’erreurs . La perte de bit , serait alors definitive ?
Un process durci , et rapide pour préserver l’échantillon et minimiser delay et latence source de guigue , est donc peut être idéal ? et exclurait alors peut être l’usage de liaisons aériennes ..? Pour le moment ? …
Alors peut-être oui , avez vous raison de soigner votre infrastructure filaire .?
Vos avis svp , 
(Cette guigue introduirai une imprécision temporelle dans le flux isochrone , et cela pourrai se percevoir notamment par une imprécision de l’image stéréo , et de la juste et précise localisation des différents . pupitres et instruments (: effet brouillon…)).?…. 
..
Merci,
Bien cordialement Willy ,
Et mes excuses encore pour le Wookie de geek post cyber punk abscons svp ..
De plus , 
Certains argueront qu’aux vues de l’extreme sensibilité des signaux passant de l’ip au Dac , de la  mauvaise qualité de l’usb 2.o Audio il serait mieux d’intégrer le Dac au streamer .??? a l’instar d’un Mola Mola , Bricasti ,Dcs , Meitner , Weiss , ou Naïm .., en plus de l’option AES 67 avec Dante , Ravenna ,liveWire ..que j’avoue méconnaître…?
--
			
				
Dernière édition par 
KIKIWILLYBEE le 30 Avr 2022 à 19:23, édité 1 fois.