Top config PC MAO 2019 (test, bench, discussion, débat...)
- 1 600 réponses
- 70 participants
- 96 120 vues
- 81 followers
Afficher le sujet de la discussion
Oui, c’est ce qu’on appelle les « lignes PCI » (PCI Lane en anglais) qu’il ne faut pas confondre avec les slots PCI, leur format et leur capacité en relation avec leur format. J’en avais déjà parlé ici et ici.
Je copie/colle les deux extraits à propos et résume ensuite :
_____
_____
Autrement dit :
Les CM comportent plusieurs slots et connecteurs se partageant le maximum de « PCI Lane » rendu possible par ces slots et connecteurs, mais étant aussi directement dépendant du maximum de « PCI Lane » que permet tel ou tel CPU.
Par exemple, à l’époque où j’ai écrit ces messages, il y avait, pour la CM ROG RAMPAGE VI EXTREME, 2 types de processeurs compatibles avec cette dernière : des CPU fournissant un maximum de 44-LANE et des CPU fournissant un maximum de 28-LANE. On peut le constater quand on observe les specs des CM, comme ici :
Donc, même si l’on fait le décompte de toutes les « PCI Lane » dispo en relation avec le nombre de slots et connecteurs d’une CM, si le CPU qu’on lui met au cul, lui, permet d’en exploiter moins que le total de la CM, ben nous serons limités par le CPU.
C’est aussi ce qui explique, en partie, pourquoi certains CPU de certaines gammes (sous LGA2066, et/ou série « X » ou Xeon, P. Ex., ) sont plus dispendieux, parce qu’en plus d’être plus « puissants », certains permettent l’exploitation de plus de « PCI Lane »
Et c’est la même chose avec les CM. Selon leur schéma de conception sur le PCB, certaines vont repartir différemment et les moins dispendieuses vont partager la gestion du nombre total de « PCI Lane » entre certaines slots et connecteurs.
Au final, ce qu’il faut saisir, c’est que le nombre maximal de « PCI Lane » de notre PC dépend du couple CM + CPU. Faut donc s’assurer que notre CPU permet autant de « PCI Lane » qu’on a besoin en plus de s’assurer que notre CM permet l’exploitation de ce nombre maximale sans trop partager ce nombre entre ses différents slots et connecteur!
Oui, ce n’est pas simple, car faut impérativement éplucher les specs des CM et des CPU. Et c’est pourquoi, P. Ex., que les CM sous certains chipset/LGA (LGA2066 P. E.x et/ou pour Xeon) sont plus cher, car étant moins limité et partageant moins les « PCI Lane » entre tous leurs slots et connecteurs.
Voilà pourquoi je mentionne souvent, depuis la V2018 de ce thread, que pour ceux qui bossent en très basse latence, il vaut mieux encore, par précaution, privilégier Intel. Et c’est aussi pourquoi j’ai posté à quelques reprises certains bench qui ont aussi relevé ce problème depuis les tout premiers Ryzen.
Ça semble s’améliorer à chaque nouvelle génération (selon certaines bench/sites), mais je ne suis pas encore tout à fait rassuré à cause de certains cas comme le tien.
Par contre, faut préciser, et c’est ce qui doit expliquer que tous les possesseurs de Ryzen n’éprouvent pas ces (tes) problèmes, que ça dépend de 3 facteurs/conditions :
1- le fait de bosser avec un buffer à moins de 128smp! Et avec les années, en participant et lisant plusieurs forums, j’ai constaté que la latence n’a pas la même importance pour tous. Par exemple, presque tous ceux qui font de l’EDM/Rap (et similaire sous Ableton, FL et Reason, surtout) bossent au-delà de 64smp parce que dû à la nature de leur musique, même s’ils utilisent des contrôleurs Midi en temps réel (launchpad et clavier), ben 128smp, 256smp, voir 512smp est suffisant pour plaquer quelques accords et démarrer des séquences/patterns/beats.
Idem avec certains qui font de gros projets orchestraux, mais en utilisant des logiciels de notation comme Sibelius et consorts (ou qui composent directement via le piano roll). Puisqu’eux ne jouent pas au clavier en temps réel, ces derniers n’abaissent pas leur buffer en deçà de 512smp~256smp pour la plupart.
Et sinon, il y a aussi des utilisateurs qui, peu importe ce qu’ils font, font rarement des projets de plus de 30 pistes, ce qui n’est pas très exigeant en ressources.
Donc eux tous sont bcp moins susceptibles de subir des glitch audio!
2- l’interface audio utilisée! Par exemple, il est clair que celui qui possède une RME Babyface Pro (et/ou une interface TB) n’obtiendra pas des glitch à la même valeur de buffer que celui qui utilise une Steinberg UR44 ou une Scarlet 2i2 (ou ma Roland Quad-Capture), P. Ex. Parce que déjà, pour une même valeur de buffer (et malgré la correspondance théorique de la latence), une RME Babyface Pro induit presque la moitié de la latence effective réelle pour une même valeur de buffer VS plusieurs autres interfaces audio de gamme inférieur. Ce qui fait que pour une latence qui nous convient à, disons, 128smp avec une BFP, il faut descendre à 64smp pour obtenir la même avec d'autres interface audio.
Par exemple, la Babyface Pro génère une RTL d’environ 4.3ms à 64smp alors que ma Roland Quad-Capture génère une latence de 7.6ms à 64smp. En 128smp, la Babyface Pro génère une RTL de 7.32ms. Qu’est-ce que ça implique? Que si je possédais une Babyface Pro, je pourrais mettre le buffer à 128smp pour avoir au final exactement la même latence que j’obtiens présentement (et qui me satisfait) à 64smp avec ma Roland Quad-Capture... ...mais tout en exploitant moins de ressources système!
Donc avec un Ryzen, entre une Quad à 64smp et une BFP à 128smp, toutes deux générant pourtant la même RTL à ces valeurs, ça pourra faire la différence entre la première qui glitch et pas la 2e!
Conséquemment, ces 2 facteurs (type de projet + jeux en temps réel au clavier ou via soft de notation/piano roll) + interface audio (qualité des pilotes + latence RTL) font que les problèmes de glitch des Ryzen (mais aussi chez Intel) ne sont pas systématique chez tous les utilisateurs.
À cela s’ajoute un 3e facteur, celui du DAW utilisé, qui peut jouer quelque peu, mais comme l’avait démontrée ma série de tests suivant l’achat de mon 8700K, sauf bug particulier lors de la sortie d’une toute nouvelle version d’un DAW, les différences ne sont pas énorme de l’un à l’autre.
Par exemple, lors de ce bench, sauf le bug de la v4 de SO et FL Studio, tous les autres DAW pouvaient faire jouer entre 21~22 instances de u-he Diva sans glitch avec le buffer de ma Roland Quad-Capture à 32smp :
Donc, oui, parfois tel ou tel DAW peut moins bien s’en sortir qu’un autre, mais de façon générale ça ne semble pas avoir tant d’incidence (constaté aussi ailleurs sur d’autres forums que je fréquente). Par contre, faut savoir bien configurer les diverses options de son DAW.
Sinon, l’on pourrait rajouter un 4e facteur, celui de prendre le soin d’effectuer les optimisations de base pour une utilisation MAO (je ne cause pas de tweaks en profondeur, juste des 4, 5 trucs de base), comme désactiver l’économie d’énergie, etc., mais je prends pour acquis que ceux qui éprouvent des problèmes de glicth, peu importe leur CPU et DAW, connaissent déjà et font ce qui s’impose à ce niveau.
Mais, bref, je voulais juste tenter d’expliquer pourquoi les problèmes de glitch avec les Ryzen ne sont pas systématiques et pourquoi plusieurs utilisateurs semblent 100% satisfaits! Ça dépend toujours des usages de chacun et de l’interface audio, entre autres.
À l’époque de ma série de tests, pendant les 6 mois qui ont suivi (j’ai la flemme de retrouver le passage), j’ai tenté à deux reprises de retirer ma GeForce GTX 1060 GAMING X 6G pour passer sur la chip graphique du CPU. Que ce soit en observant avec LatencyMoon ou que ce soit en pratique, je n’ai jamais pu observer de différences significatives. Alors j’ai fini, après 2 swicths, 2 expériences (2 périodes de quelques semaines avec la GeForce et 2 périodes sans) par remettre ma GeForce pour de bon, car elle ne créait manifestement pas d’interruption intempestive (je vérifiais avec le gestionnaire des tâches de Win, bien sûr, mais aussi avec des utilitaires spécialisés, comme « Process Explorer » et « Process Monitor », entre autres, qu’on peut récupérer ici).
Par contre, comme je l’avais lu ici et là sur certains forums, je n’installe pas cette connerie de « Nvidia Experience » qui, selon certains utilisateurs, serait le process (en tâche de fond) qui créer des glitch.
Dans mon cas (pour ceux qui ont suivi mes expériences à l’époque), j’obtenais bel et bien une espèce de « micro-coupure » intempestive (avec et sans la carte Nvidia) qui revenait à toutes les 10mn, mais elle ne mérite même pas d’être qualifiée de glitch. C’était, avec le buffer à 64smp, une seule et unique micro-coupure qui revenait une fois toutes les 10 minutes environ (ça n’aurait pas perturbé la plupart des utilisateurs, mais moi suis très exigeant... ...quand je paie près de 4000$ CA pour un PC!
). Après plusieurs mois à éplucher tous les process de W10 (en filmant des utilitaires spécialisés de process en temps réel avec mon smartphone), j’ai enfin trouvé ce qui provoquait ceci chez moi : j’ai désactivé ces 2 lignes/tâches dans le planificateur de tâche :
...et depuis tout beigne avec le buffer de ma Roland Quand-Capture à 64smp. Tu pourrais peut-être faire de même et observer si ça change quoi que ce soit chez toi!
Mais pour revenir aux cartes Nvidia, elles ne semblent pas causer de problème de façon systématique et c’est probablement surtout ceux qui ne prennent pas le soin de lire et décocher certains trucs non nécessaires lors de l’installation du pilote, comme le « Nvidia Experience » qui obtiennent des glitch.
Hâ. Par contre et c'est peut-être utile que je le partage, mais il y a depuis quelques années 2 familles spécifiques de pilotes Nvidia. Lorsque vous recherchez le pilote pour votre carte Nvidia sur le site, il y a une version nommée « Game Ready Drivers » (optimisé pour le jeu) et une autre nommée « Studio Driver » (optimisé pour les stations de travail). Moi j'ai choisi cette dernière. De plus, puisque tout beigne, je ne l'ai jamais updaté depuis (c'est la règle d'or en informatique lorsque tout baigne : pas touche, pas d'update!
).
Voici la version du pilote que j'utilise sous mon PC dédié à la MAO avec ma GeForce GTX 1060 GAMING X 6G (431.86-desktop-win10-64bit-international-nsd-whql Studio):
EDIT :
Oui, je sais, avec W10 ce dernier télécharge et installe automatiquement le pilote pour la carte vidéo, mais moi je ne fais pas confiance et de toute façon, pour un PC dédié MAO, il vaut mieux (avec une crate Nvidia) choisir le pilote « Studio Driver » directement sur le site.
Du coup, lorsque tous vos pilotes sont bel et bien installés (après une fresh install de l'OS, P. Ex.), il est préférable d'aller dans Démarrer ==> Système ==> Informations système ==> Paramètres système avancé (colonne de gauche) ==> onglet matériel ==> bouton Paramètres d'installation des périphériques ==> sélectionnez l'option « Non » à la question « Voulez-vous télécharger automatiquement les applications des fabricants et les icônes personnalisées disponibles pour vos appareils » et cliquer sur « Enregistrer les modifications ». ...juste pour s'assurer que W10 ne tente pas d'installé l'autre version du pilote graphique quand ça lui chante :
Au pire, juste à réactiver cette option lors de l'achat d'un nouveau périphérique tout juste avant de le connecter (certains ont besoin que W10 recherche le pilote automatiquement) et de le re-désactiver ensuite.
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de cortez77 :
...mais certaines configs ont un nombre limité de canaux PCI-E (j'utilise peut être le mauvais terme technique), et si pas exemple vous avez 6 prises SATA et 2 M.2, utiliser les M.2 va désactiver 2 des SATA.
Oui, c’est ce qu’on appelle les « lignes PCI » (PCI Lane en anglais) qu’il ne faut pas confondre avec les slots PCI, leur format et leur capacité en relation avec leur format. J’en avais déjà parlé ici et ici.
Je copie/colle les deux extraits à propos et résume ensuite :
Citation de Darkmoon :
Mais ce n'est pas aussi simple (informatique oblige!)...
Car faut aussi savoir qu'il y a 2, 3 formats (les longueurs et le nombre de broches différent) de connecteur PCIe dans les cartes mères récentes : x16 et x1 (parfois x4) et ces nombres correspondent à la longueur des différents connecteurs PCIe. Il représente aussi le nombre maximal de « lignes » (espèce de « tunnel de transport de données », pour vulgariser) que peut exploiter le connecteur (sauf pour la 3e slot x16 qui paradoxalement est souvent limité en x4 en pratique) et donc du débit maximal qu'ils peuvent exploiter. Mais encore, il y a aussi la somme totale de toutes les lignes présentes et disponibles (dans la carte-mère qui attribue aussi des lignes PCIe aux slots M.2) qui importe, ce qui fait que, très souvent, sur les cartes-mères « grand public », même si nous avons 2 ou 3 connecteurs PCIe x16 et 3 connecteurs PCIe x1, ils ne peuvent pas tous nécessairement utiliser toutes leurs lignes PCIe (« tunnels » de données) simultanément selon ce qui est connecté ou non sur les connecteurs PCIe et selon si les (ou un la plupart du temps) connecteur M.2 sont utilisé en mode PCIe. L'exemple le plus courant étant que deux cartes vidéo (en mode Cross/SLI) enfichées chacune dans des slots x16 ne pourront fonctionner qu'en mode partagé x8.
Exemple de specs concernant les slots/lignes PCIe et les différents modes partagé :
Exemple des specs des connecteurs M.2 où l'on voit que seul l'un des deux peut fonctionner autant en mode PCIe qu'en mode SATA. L'autre fonctionnant uniquement qu’en mode PCIe et que le premier connecteur M.2 est partagé avec le connecteur SATA_1:
Sinon, il y a d'autres cas où faut faire attention, bien se renseigner et bien lire les notices. Par exemple, je possède une carte d'acquisition vidéo Blackmagic Intensity Pro 4K (afin de pouvoir exploiter une vieille cam HDV via HDMI) avec une très petite fiche qui semble, a priori, devoir s'enficher dans un court slot PCIe x1, mais non, elle doit tout de même être enfiché dans l'un des 3 slots x16 (même si sa fiche de connections est plus petite que le slot x16) puisqu'elle nécessite l'utilisation d'au moins 4 lignes PCIe (comme indiqué ici):
Bref, si l'on désire utiliser des adapteurs pour connecter des disques SSD sur des slots PCIe et tout un tas d'autres cartes simultanément, faut s'assurer de ce que les cartes et les disques requièrent en nombre de lignes PCIe afin de pouvoir fonctionner à leur maximum de bande passante. Et c'est là, souvent, que les carte-mères « gamer » ou « grand public » sont plus limitées. Faut alors se tourner vers des cartes-mères dites « workstation» (pour Xeon) comme celle-ci (souvent plus chère) qui comportent 4 slost x16 et où les 2 connecteurs M.2 peuvent fonctionner simultanément en mode PCIe.
_____
Citation de Darkmoon :
Par exemple, si tu désire mettre plusieurs SSDs Nvme en RAID, faut juste t'assurer que la carte mère le permet et t'assurer, en lisant les specs, que les slots/lignes ne sont pas partagées avec d'autres slot sPCIe et M.2 et/ou que le nombre de lignes est suffisant (en rapport avec le nombre de lignes que peut gérer ton processeur. Un point que j'ai oublié d'aborder!).
Ça implique « juste »de passer un soirée (et un mal de crâne
Par exemple, là, je vois (je reste dans le Intel) que la carte « gaming » ROG RAMPAGE VI EXTREME :
- supporte 128GB de RAM,
- possède 5 slots PCIe au total dont 4 jusqu'à x16 pouvant fonctionner simultanément en : x16/x0/x16/x8 ou x16/x8/x8/x8 avec un CPU pouvant gérer 44 lignes ou en x16/x8 ou x8/x8/x8 avec un CPU pouvant gérer 28 lignes,
- une 1 slot PCIe x4 indépendant des autres,
- un connecteur U.2 (pour disque NVMe et dont j'ai oublié de mentionner dans mon long pavé),
Un socket M.2 (pour disque SATA/NVMe),
2 slots DIMM2 (pour disques NVMe et dont j'ai aussi oublié de parler dans mon long pavé),
6 ports SATA,
Etc, etc.
Donc, a priori, l'on pourrait penser pouvoir connecter sur cette carte mère : 6 SSD SATA (format petit boîtier) sur les 6 ports SATA + 2 SSD NVMe au format « M.2 2230~22110 » sur les 2 DIMM2 (PCIe) + 1 disque SSD NVMe (et/ou SATA si je ne me trompe pas) sur le connecteur U.2 + 1 SSD NVMe ou SATA sur le connecteur M.2 + 3 SSD NVMe (format carte ou avec adaptateur) sur au moins 3 slots PCIe (en x4~x8, car conservons en une en x16 pour une carte vidéo et la slot 4x indépendante pour une autre carte éventuelle, par sécurité).
...pour un total d'au moins, a priori, 13 disques SSD dont au moins 7 en mode PCIe (2.5Go/s en pratique et les autres en mode SATA, donc à ± 500Mo/s).
Reste juste à vérifier ce qui est partagé :
Donc, éliminons l'utilisation du connecteur U.2 puisqu'il semble partager le bandwith avec la slot DDIMM2 (quoique ce serait possible avec des disques en mode SATA, je crois).
Sinon, la 4e slot PCIe fonctionnera en 4x si le 2e connecteur DIMM2 est occupé. Mais 4x demeure suffisant pour faire tourner un SSD NVMe en mode PCIe (ou une carte d'acquisition quelconque jusqu'en 4x) puisque dans la notice du 960 EVO NVMe M.2, l'on peut lire ceci :
Donc, jusque-là, disons que nous pourrions connecter (sans utiliser le connecteur U.2) 12 disques SSD dont 6 disques SSD 960 EVO NVMe en mode PCIe (les 6 autres en boitier/SATA sur les 6 connecteurs SATA).
_____
Autrement dit :
Les CM comportent plusieurs slots et connecteurs se partageant le maximum de « PCI Lane » rendu possible par ces slots et connecteurs, mais étant aussi directement dépendant du maximum de « PCI Lane » que permet tel ou tel CPU.
Par exemple, à l’époque où j’ai écrit ces messages, il y avait, pour la CM ROG RAMPAGE VI EXTREME, 2 types de processeurs compatibles avec cette dernière : des CPU fournissant un maximum de 44-LANE et des CPU fournissant un maximum de 28-LANE. On peut le constater quand on observe les specs des CM, comme ici :
Donc, même si l’on fait le décompte de toutes les « PCI Lane » dispo en relation avec le nombre de slots et connecteurs d’une CM, si le CPU qu’on lui met au cul, lui, permet d’en exploiter moins que le total de la CM, ben nous serons limités par le CPU.
C’est aussi ce qui explique, en partie, pourquoi certains CPU de certaines gammes (sous LGA2066, et/ou série « X » ou Xeon, P. Ex., ) sont plus dispendieux, parce qu’en plus d’être plus « puissants », certains permettent l’exploitation de plus de « PCI Lane »
Et c’est la même chose avec les CM. Selon leur schéma de conception sur le PCB, certaines vont repartir différemment et les moins dispendieuses vont partager la gestion du nombre total de « PCI Lane » entre certaines slots et connecteurs.
Au final, ce qu’il faut saisir, c’est que le nombre maximal de « PCI Lane » de notre PC dépend du couple CM + CPU. Faut donc s’assurer que notre CPU permet autant de « PCI Lane » qu’on a besoin en plus de s’assurer que notre CM permet l’exploitation de ce nombre maximale sans trop partager ce nombre entre ses différents slots et connecteur!
Oui, ce n’est pas simple, car faut impérativement éplucher les specs des CM et des CPU. Et c’est pourquoi, P. Ex., que les CM sous certains chipset/LGA (LGA2066 P. E.x et/ou pour Xeon) sont plus cher, car étant moins limité et partageant moins les « PCI Lane » entre tous leurs slots et connecteurs.
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
Freudon
652
Posteur·euse AFfolé·e
Membre depuis 19 ans
Mus'images
356
Posteur·euse AFfamé·e
Membre depuis 8 ans
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de Ericmusicstrasbourg :
...du coup je craque et j'achete un ryern 7 3700x. mais à mon grand regret pour des raisons inconnus (au depart) ca glitsch dans tous les sens
[...]
Du coup je recraque et et je monte un ryzen9 3900x... ok en effet la puissance de calcul est tout autre mais il y a un mais...
En basse latence 64 samples le i9 ne sature pas (pas de glitsch audio) mais ça consomme beaucoup suivant les banks... sur le ryzen c’est pas pareil!!! Ça glitsch pas mal!
Voilà pourquoi je mentionne souvent, depuis la V2018 de ce thread, que pour ceux qui bossent en très basse latence, il vaut mieux encore, par précaution, privilégier Intel. Et c’est aussi pourquoi j’ai posté à quelques reprises certains bench qui ont aussi relevé ce problème depuis les tout premiers Ryzen.
Ça semble s’améliorer à chaque nouvelle génération (selon certaines bench/sites), mais je ne suis pas encore tout à fait rassuré à cause de certains cas comme le tien.
Par contre, faut préciser, et c’est ce qui doit expliquer que tous les possesseurs de Ryzen n’éprouvent pas ces (tes) problèmes, que ça dépend de 3 facteurs/conditions :
1- le fait de bosser avec un buffer à moins de 128smp! Et avec les années, en participant et lisant plusieurs forums, j’ai constaté que la latence n’a pas la même importance pour tous. Par exemple, presque tous ceux qui font de l’EDM/Rap (et similaire sous Ableton, FL et Reason, surtout) bossent au-delà de 64smp parce que dû à la nature de leur musique, même s’ils utilisent des contrôleurs Midi en temps réel (launchpad et clavier), ben 128smp, 256smp, voir 512smp est suffisant pour plaquer quelques accords et démarrer des séquences/patterns/beats.
Idem avec certains qui font de gros projets orchestraux, mais en utilisant des logiciels de notation comme Sibelius et consorts (ou qui composent directement via le piano roll). Puisqu’eux ne jouent pas au clavier en temps réel, ces derniers n’abaissent pas leur buffer en deçà de 512smp~256smp pour la plupart.
Et sinon, il y a aussi des utilisateurs qui, peu importe ce qu’ils font, font rarement des projets de plus de 30 pistes, ce qui n’est pas très exigeant en ressources.
Donc eux tous sont bcp moins susceptibles de subir des glitch audio!
2- l’interface audio utilisée! Par exemple, il est clair que celui qui possède une RME Babyface Pro (et/ou une interface TB) n’obtiendra pas des glitch à la même valeur de buffer que celui qui utilise une Steinberg UR44 ou une Scarlet 2i2 (ou ma Roland Quad-Capture), P. Ex. Parce que déjà, pour une même valeur de buffer (et malgré la correspondance théorique de la latence), une RME Babyface Pro induit presque la moitié de la latence effective réelle pour une même valeur de buffer VS plusieurs autres interfaces audio de gamme inférieur. Ce qui fait que pour une latence qui nous convient à, disons, 128smp avec une BFP, il faut descendre à 64smp pour obtenir la même avec d'autres interface audio.
Par exemple, la Babyface Pro génère une RTL d’environ 4.3ms à 64smp alors que ma Roland Quad-Capture génère une latence de 7.6ms à 64smp. En 128smp, la Babyface Pro génère une RTL de 7.32ms. Qu’est-ce que ça implique? Que si je possédais une Babyface Pro, je pourrais mettre le buffer à 128smp pour avoir au final exactement la même latence que j’obtiens présentement (et qui me satisfait) à 64smp avec ma Roland Quad-Capture... ...mais tout en exploitant moins de ressources système!
Donc avec un Ryzen, entre une Quad à 64smp et une BFP à 128smp, toutes deux générant pourtant la même RTL à ces valeurs, ça pourra faire la différence entre la première qui glitch et pas la 2e!
Conséquemment, ces 2 facteurs (type de projet + jeux en temps réel au clavier ou via soft de notation/piano roll) + interface audio (qualité des pilotes + latence RTL) font que les problèmes de glitch des Ryzen (mais aussi chez Intel) ne sont pas systématique chez tous les utilisateurs.
À cela s’ajoute un 3e facteur, celui du DAW utilisé, qui peut jouer quelque peu, mais comme l’avait démontrée ma série de tests suivant l’achat de mon 8700K, sauf bug particulier lors de la sortie d’une toute nouvelle version d’un DAW, les différences ne sont pas énorme de l’un à l’autre.
Par exemple, lors de ce bench, sauf le bug de la v4 de SO et FL Studio, tous les autres DAW pouvaient faire jouer entre 21~22 instances de u-he Diva sans glitch avec le buffer de ma Roland Quad-Capture à 32smp :
Donc, oui, parfois tel ou tel DAW peut moins bien s’en sortir qu’un autre, mais de façon générale ça ne semble pas avoir tant d’incidence (constaté aussi ailleurs sur d’autres forums que je fréquente). Par contre, faut savoir bien configurer les diverses options de son DAW.
Sinon, l’on pourrait rajouter un 4e facteur, celui de prendre le soin d’effectuer les optimisations de base pour une utilisation MAO (je ne cause pas de tweaks en profondeur, juste des 4, 5 trucs de base), comme désactiver l’économie d’énergie, etc., mais je prends pour acquis que ceux qui éprouvent des problèmes de glicth, peu importe leur CPU et DAW, connaissent déjà et font ce qui s’impose à ce niveau.
Mais, bref, je voulais juste tenter d’expliquer pourquoi les problèmes de glitch avec les Ryzen ne sont pas systématiques et pourquoi plusieurs utilisateurs semblent 100% satisfaits! Ça dépend toujours des usages de chacun et de l’interface audio, entre autres.
Citation de Ericmusicstrasbourg :
A ça je rajoute la carte graphique... Nvidia propose des Drivers optimisés pour des jeux, mais parfois ça ralentit fortement le traitement audio [...] Les Soft dpc latency et latency (conseillé par darkmoon et freudon) me permettront de voir si ça traîne un peu du coté driver ou sur un périphérique. Les cartes graphiques AMD seraient mieux développer niveau driver... je n’ai pas pu vérifier cette information.
À l’époque de ma série de tests, pendant les 6 mois qui ont suivi (j’ai la flemme de retrouver le passage), j’ai tenté à deux reprises de retirer ma GeForce GTX 1060 GAMING X 6G pour passer sur la chip graphique du CPU. Que ce soit en observant avec LatencyMoon ou que ce soit en pratique, je n’ai jamais pu observer de différences significatives. Alors j’ai fini, après 2 swicths, 2 expériences (2 périodes de quelques semaines avec la GeForce et 2 périodes sans) par remettre ma GeForce pour de bon, car elle ne créait manifestement pas d’interruption intempestive (je vérifiais avec le gestionnaire des tâches de Win, bien sûr, mais aussi avec des utilitaires spécialisés, comme « Process Explorer » et « Process Monitor », entre autres, qu’on peut récupérer ici).
Par contre, comme je l’avais lu ici et là sur certains forums, je n’installe pas cette connerie de « Nvidia Experience » qui, selon certains utilisateurs, serait le process (en tâche de fond) qui créer des glitch.
Dans mon cas (pour ceux qui ont suivi mes expériences à l’époque), j’obtenais bel et bien une espèce de « micro-coupure » intempestive (avec et sans la carte Nvidia) qui revenait à toutes les 10mn, mais elle ne mérite même pas d’être qualifiée de glitch. C’était, avec le buffer à 64smp, une seule et unique micro-coupure qui revenait une fois toutes les 10 minutes environ (ça n’aurait pas perturbé la plupart des utilisateurs, mais moi suis très exigeant... ...quand je paie près de 4000$ CA pour un PC!
). Après plusieurs mois à éplucher tous les process de W10 (en filmant des utilitaires spécialisés de process en temps réel avec mon smartphone), j’ai enfin trouvé ce qui provoquait ceci chez moi : j’ai désactivé ces 2 lignes/tâches dans le planificateur de tâche :...et depuis tout beigne avec le buffer de ma Roland Quand-Capture à 64smp. Tu pourrais peut-être faire de même et observer si ça change quoi que ce soit chez toi!
Mais pour revenir aux cartes Nvidia, elles ne semblent pas causer de problème de façon systématique et c’est probablement surtout ceux qui ne prennent pas le soin de lire et décocher certains trucs non nécessaires lors de l’installation du pilote, comme le « Nvidia Experience » qui obtiennent des glitch.
Hâ. Par contre et c'est peut-être utile que je le partage, mais il y a depuis quelques années 2 familles spécifiques de pilotes Nvidia. Lorsque vous recherchez le pilote pour votre carte Nvidia sur le site, il y a une version nommée « Game Ready Drivers » (optimisé pour le jeu) et une autre nommée « Studio Driver » (optimisé pour les stations de travail). Moi j'ai choisi cette dernière. De plus, puisque tout beigne, je ne l'ai jamais updaté depuis (c'est la règle d'or en informatique lorsque tout baigne : pas touche, pas d'update!
).Voici la version du pilote que j'utilise sous mon PC dédié à la MAO avec ma GeForce GTX 1060 GAMING X 6G (431.86-desktop-win10-64bit-international-nsd-whql Studio):
EDIT :
Oui, je sais, avec W10 ce dernier télécharge et installe automatiquement le pilote pour la carte vidéo, mais moi je ne fais pas confiance et de toute façon, pour un PC dédié MAO, il vaut mieux (avec une crate Nvidia) choisir le pilote « Studio Driver » directement sur le site.
Du coup, lorsque tous vos pilotes sont bel et bien installés (après une fresh install de l'OS, P. Ex.), il est préférable d'aller dans Démarrer ==> Système ==> Informations système ==> Paramètres système avancé (colonne de gauche) ==> onglet matériel ==> bouton Paramètres d'installation des périphériques ==> sélectionnez l'option « Non » à la question « Voulez-vous télécharger automatiquement les applications des fabricants et les icônes personnalisées disponibles pour vos appareils » et cliquer sur « Enregistrer les modifications ». ...juste pour s'assurer que W10 ne tente pas d'installé l'autre version du pilote graphique quand ça lui chante :
Au pire, juste à réactiver cette option lors de l'achat d'un nouveau périphérique tout juste avant de le connecter (certains ont besoin que W10 recherche le pilote automatiquement) et de le re-désactiver ensuite.
"Si t'enregistres à Poudlard, avec l'ingé son Dumbledore, les lois physiques tu peux t'en foutre. Mais dans l'monde réel, les lois physiques, les mesures, le dBFS, tout ça existe bel et bien." youtou
[ Dernière édition du message le 30/06/2020 à 02:33:29 ]
JohnnyG
10317
Drogué·e à l’AFéine
Membre depuis 15 ans
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
Mus'images
356
Posteur·euse AFfamé·e
Membre depuis 8 ans
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
Pat.Rick
285
Posteur·euse AFfamé·e
Membre depuis 19 ans
- < Liste des sujets
- Charte