L'accessoire de l'année (MDR)

[Roberto]

(07-03-2016, 07:05 PM)Haïm a écrit : 2 - "ça reconditionne les donnees avec une horloge de haute précision" : Là ça confine au sublime. Synchroniser une communication asynchrone   . l'USB c'est un anneau à jeton, leur truc relève de l'eau déshydratée.

Le tout pour 249 euros ! Remarquez, moi j'ai bien payé 6,50 pour leurs conneries alors....

Oh punaise...! Si j'avais lu avant ce thread j'aurais pu économiser plus de 200€!!
Non mais sérieusement...Le fait est que ça marche vraiment le Recovery!

Enfin avec 6,50 € vous avez gagné de la bonne humeur et du rire, et ceci de nos temps n'a pas de prix...

[0000]

Ces boîtiers magiques, comment ils fonctionnent précisément ? Seulement "nettoyer" les "bruits" ? Sans toucher le volume sonore ... ?

[Haïm]

Merci à Bkg2k pour ces pertinentes précisions. Effectivement le protocole USB est un truc à multi tiroirs.

Maintenant la question qui me brûle le clavier c'est : pourquoi ont ils choisi le sous-protocole sans correction d'erreur ?! C'est vraiment du masochisme ! On sait très bien que l'USB utilisé en informatique pure ne perds aucun octets. D'accord il faut un bon buffer côté récepteur pour, dans le cas d'une erreur, avoir le temps de redemander le paquet défectueux sans tomber à sec. Soit quelques € de composants...

D'ailleurs je ne sais pas quel périphérique choisi le mode, l'émetteur (pc) ou le récepteur (dac) ?

[ajls]

je profite de la mi temps et du manque d'intérêt actuel du match...
je redis le truc. on est à mon avis en train de diverger sur la notion de SOURCE.
on accumule des boîtes selon une logique non démontrée et qui n'apporte pas grand chose si ce n'est accumuler des problèmes et on ne progresse pas comme ça a été et c'est encore le cas pour le vinyl ou le cd.
cette notion de source est largement perdue de vue.
je ne nie pas les efforts sincères de beaucoup pour optimiser tout ça mais c'est vain pour l'instant à mon sens.
jetez un coup d'œil voire une oreille sur les soluces linn, c'est mieux (jugement perso bien sûr). ce sont (me semble t il) historiquement les premiers à avoir laissé tomber le cd pour developper la démat. 
je provoque mais pas que...

[0000]

Je reposte un texte trouvé sur le web, mais avec un lien plus commode (version pdf).
Fundamentals of USB-Audio

[Bkg2k]

(07-06-2016, 09:23 PM)Haïm a écrit : Merci à Bkg2k pour ces pertinentes précisions. Effectivement le protocole USB est un truc à multi tiroirs.

Maintenant la question qui me brûle le clavier c'est : pourquoi ont ils choisi le sous-protocole sans correction d'erreur ?! C'est vraiment du masochisme ! On sait très bien que l'USB utilisé en informatique pure ne perds aucun octets. D'accord il faut un bon buffer côté récepteur pour, dans le cas d'une erreur, avoir le temps de redemander le paquet défectueux sans tomber à sec. Soit quelques € de composants...

D'ailleurs je ne sais pas quel périphérique choisi le mode, l'émetteur (pc) ou le récepteur (dac) ?

Pourquoi ils ont choisi un protocole sans correction d'erreur?
A cause de la reservation de bande passante. La bande passante maximum de l'USB 2 sur lequel repose l'USB Audio est de 480Mb/s (informations protoclaires comprise, comme chaque fois qu'on exprime une BP en bits/seconde)

Si on veut jouer du stéréo en qualité CD, on va envoyer 2 (stéréo) x 44100 (fréquence) x 16 bits, soir 1411200 bits ar seconde. Disons 1600kbits/s environ avec l'empaquetage et le protocole.
Donc l’émetteur, qui contrôle la ligne USB, va réserver 1600kb/s pour le DAC. Cette BP est donc tout juste suffisante pour jouer en continue le CD stéréo. De fait, il n'y a pas de place pour lé réémission de données en cas d'erreur.
C'est un choix qu'on fait les concepteurs. Il est certes discutable...

[0000]

(07-07-2016, 12:50 PM)Bkg2k a écrit : Donc l’émetteur, qui contrôle la ligne USB, va réserver 1600kb/s pour le DAC. Cette BP est donc tout juste suffisante pour jouer en continue le CD stéréo. De fait, il n'y a pas de place pour lé réémission de données en cas d'erreur.
C'est un choix qu'on fait les concepteurs. Il est certes discutable...

Pas compris la phrase souligné. Pourquoi l'émetteur ne réserve pas plus de BP ?

Il me semble que le choix pour usb audio se faisait entre les types de transfert Bulk et Isochronous. Le problème de latence conduisait au choix de Isochronous.
( Pour voir les caractéristiques des types de transfert : http://www.beyondlogic.org/usbnutshell/usb4.shtml )

[Bkg2k]

(07-07-2016, 02:30 PM)bz31 a écrit :

(07-07-2016, 12:50 PM)Bkg2k a écrit : Donc l’émetteur, qui contrôle la ligne USB, va réserver 1600kb/s pour le DAC. Cette BP est donc tout juste suffisante pour jouer en continue le CD stéréo. De fait, il n'y a pas de place pour lé réémission de données en cas d'erreur.
C'est un choix qu'on fait les concepteurs. Il est certes discutable...

Pas compris la phrase souligné. Pourquoi l'émetteur ne réserve pas plus de BP ?

Il me semble que le choix pour usb audio se faisait entre les types de transfert Bulk et Isochronous. Le problème de latence conduisait au choix de Isochronous.
( Pour voir les caractéristiques des types de transfert : http://www.beyondlogic.org/usbnutshell/usb4.shtml )

Alors pour la reserve de BP, oui ils auraient pu reserver un peu plus. Mais combien? Pas evident d'anticiper les problemes de ligne. Mais je suis d'accord cependant, une petite reserve de 5 à 10% aurait sans doute été jouable. Je pense qu'ils n'ont pas voulu jouer sur les statistiques, préférant un protocole borné et prédictif.

Pour la suite, oui c'est ça. Le bulk et iso sont les bon termes pour le synchrone/asynchrone. Le bulk c'est un peu comme le SPDIF (j'ai dis un peu hein, j'en entends certains au fond de la salle prêts à m'égorger ) dans le sens ou l'emeteur doit être en mesure de tenir la cadence avec une relative exactitude (il y a quand même 8000 paquets de données par secondes qui transitent), ce qui est compliqué quand on envoi d'un PC généraliste et pas optimisé aux petits oignons comme le Mac Mini de Pascal64 par exemple
L'asynchrone (ou l'iso) permet au DAC de reguler ses buffers. S'il voit que l'emeteur a diminué sa cadence, il va lui redemander rapidement plusieurs paquets. Si au contraire l'emeteur a envoyé un peu trop vite, le DAC va attendre un peu avant de redemander.
C'est un peu imagé, parceque dans les faits, la regulation est au paquet près et c'est extrement rapide.

[0000]

(07-07-2016, 05:11 PM)Bkg2k a écrit : Pour la suite, oui c'est ça. Le bulk et iso sont les bon termes pour le synchrone/asynchrone.  ......

Désolé d'insister
D'après mes lectures, bulk et isochronous sont deux notions complètement différentes de synchrone et asynchrone.
Il y a 4 types de transferts : Control, Interrupt, Bulk et Isochronous. USB Audio utilise les 3 types Control, Interrupt et Isochronous. Isochronous transfert est utilisé pour envoyer les données audio, Control et Interrupt transferts sont utilisés pour autres taches annexes dont volume etc.
Ensuite, Synchrone, Asynchrone et Adaptive sont les 3 modes de synchronisation pour Isochronous transfert.

[Bkg2k]

Exact
Du coup j'ai refais quelques recherches et ça semble être ça.
Et visiblement, l'allocation de BP est faite par le mode Iso.
Par contre je trouve etrange du coup que tous les modes audio soient en Iso, puisque du coup ça signifie aucun resend en cas d'erreur, y compris en synchrone, ce qui rends ce mode... sans aucun avantage. Ca contredit ce que j'avais trouvé il y a quelques mois, et je n'arrive plus a mettre la main dessus.
Je vais creuser la question du coup

---

L'article de Bz31 version Web:
http://www.edn.com/design/consumer/43761...-USB-Audio
Et un autre dans la foulée:
http://www.edn.com/design/consumer/44033...simplified

Pas de mecanisme de resend, quelque soit le protocole audio. On comprends facilement pourquoi l'async a rapidement pris le pas... Le synchrone n'a que des inconvénients en fait.