Messages : 1,421
Sujets : 64
Inscription : Nov 2015
Type: Particulier
Localisation: Paris
mini PC Roon > LHY SW6> Teac UD-701n > (LHY OCK-2) > Audiophile Technologie Théorème et Amplitude 4 > Enceintes bricolées plus quelques bon câble
Messages : 1,900
Sujets : 24
Inscription : Dec 2015
Type: Particulier
Ces boîtiers magiques, comment ils fonctionnent précisément ? Seulement "nettoyer" les "bruits" ? Sans toucher le volume sonore ... ?
Messages : 68
Sujets : 11
Inscription : Mar 2016
Type: Particulier
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) ?
Messages : 738
Sujets : 10
Inscription : Mar 2016
Type: Particulier
Localisation: Montmartre
07-06-2016, 10:09 PM
(Modification du message : 07-06-2016, 10:10 PM par 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...
cdlt
Alain
Messages : 1,900
Sujets : 24
Inscription : Dec 2015
Type: Particulier
07-07-2016, 12:24 PM
(Modification du message : 07-07-2016, 07:05 PM par 0000.)
Je reposte un texte trouvé sur le web, mais avec un lien plus commode (version pdf).
Fundamentals of USB-Audio
Messages : 842
Sujets : 15
Inscription : Mar 2016
Type: Particulier
Localisation: 13, Autour de l'Etang
(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...
Messages : 1,900
Sujets : 24
Inscription : Dec 2015
Type: Particulier
(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 )
Messages : 842
Sujets : 15
Inscription : Mar 2016
Type: Particulier
Localisation: 13, Autour de l'Etang
(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.
Messages : 1,900
Sujets : 24
Inscription : Dec 2015
Type: Particulier
(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.
Messages : 842
Sujets : 15
Inscription : Mar 2016
Type: Particulier
Localisation: 13, Autour de l'Etang
07-07-2016, 06:49 PM
(Modification du message : 07-07-2016, 06:58 PM par 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.
|