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

[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.