Top config PC MAO 2021 (test, bench, discussion, débat...)
- 1 405 réponses
- 55 participants
- 90 203 vues
- 74 followers
Afficher le sujet de la discussion
voici les liens pour reaper test fait par Dan et Darkmoon. j'ai fait exactement le même.
Ça dépend avec quelle interface. Perso, je possède une Roland Quad-Capture (UA55) ainsi qu'une Presonus Studio 1810c. En 44.1KHz avec le buffer réglé à 64smp, la Roland génère 7.6ms de RTL et la Presonus génère 5.2ms de RTL. En comparaison, la RME Babyface Pro FS génère 4.1ms de RTL pour les mêmes valeurs. La BFP FS est, parmi toute les interfaces USB, celle qui génère le moins de latence à ma connaissance (Sinon une Scarlett 6i6 2nd Gen génère 8ms, une Steinberg UR44 9.5ms, tjrs en 44.1KHz/buffer à 64smp).
Ces valeurs ne sont pas nécessairement celles indiquées par les DAW (valeur indiquée qui peuvent être imprécise), mais les valeurs réelles effectives mesurées avec RTL Utility en branchant un câble audio d'une des sorties vers l'une des entrées de l'interface audio.
Quelques rappels...
En théorie, en 44.1KHz (= 44100 samples/s ou 44,1 samples/ms), 64smp correspond à 1.5ms (44,1 X 1.5 = 66,15smp, d'où le « 64smp » du buffer, un coup « arrondi »). Sauf que lorsque l'on branche un micro et/ou un instrument à notre interface audio, cette dernière doit procéder à une première conversion (Analog to Digital) afin de pouvoir traiter le son numériquement dans le PC, ainsi qu'à une autre au final (Digital to Analog) afin de reconvertir le signal numérique en signal analogique qui est ensuite envoyé, en sortie, sur nos moniteurs/casques.
D'où pourquoi l'on parle de « conversion AD/DA » et pourquoi, si l'on additionne la latence d'entrée à celle de sortie, à ces valeurs (44.1KHz, 64smp), une interface devrait générer, théoriquement, une latence audio total (RTL) de 3ms (1,5 + 1,5). Sauf que les pilotes des interfaces n'ont pas tous la même « efficience » et certaines interfaces peuvent posséder un « buffer » supplémentaire à l'interne.
Mais en réalité, ce n'est pas tout à fait comme ça que ça fonctionne, mais il est nécessaire de débuter par expliquer ça comme ça pour bien comprendre dans un premier temps les rapports entre les fréquences, les samples et les ms.
En fait, quand nous paramétrons le buffer de notre interface en 64smp (P. Ex., mais ça pourrait être en 32smp ou en 128smp), l'interface n'a pas « besoin » de 64smp (ou 1,5ms) pour convertir le signal, car elle peut l'effectuer par « bloc/lot/groupe » encore plus petit. C'est pourquoi nous pouvons choisir un « bloc »(buffer) de 32smp, 48smp voire même 16smp avec certaines interfaces. Le « bloc », le buffer est arbitraire en fait et choisit par nous. La limite étant la plus petite valeur disponible pour le choix du buffer. Mais cette limite est elle aussi un choix arbitraire de la part des constructeurs (nous allons comprendre plus loin), car en réalité le convertisseur (enfin, certains) procède à la conversion encore plus rapidement que la plus petite valeur de buffer disponible.
Autrement dit, les convertisseurs AD/DA des interfaces ont en réalité besoin de moins de temps que la plus petite valeur de buffer disponible pour convertir le signal et ce temps de traitement n'est pas nécessairement partagé au public par tous les constructeurs. Les valeurs de buffers (paramétrable par l'utilisateur), elles, ne sont que des « tailles de lots », des « blocs » de traitement arbitraire, que nous pouvons choisir, et qui ne servent qu'à laisser une marge, un laps de temps au processeur de notre PC dans le cas où, entre la conversion d'entrée et celle de sortie, nous appliquerions un effet numérique dans la « boucle », dans le « trajet » du signal audio.
Et c'est là que certains débutants confondent souvent en croyant que la puissance du processeur « améliore » et/ou influe sur la latence générée par les interfaces audio alors que ce n'est pas le cas du tout. La puissance du processeur n'influe que sur le nombre de traitements numérique (VSTi/VST) pouvant être calculé à l'intérieur d'un laps de temps donné. C'est totalement différent! En principe, si nous ouvrons notre DAW, n'ajoutons aucun traitement et ne touchons à rien, même pas au fader de la piste audio (en écoute de l'entrée Inst/Mic/Line), nous devrions pouvoir utiliser notre interface audio avec la plus petite valeur de buffer disponible sans aucun glitch (et c'est effectivement le cas chez moi), peu importe le processeur.
À ce point, nous devons saisir qu'en réalité les convertisseurs AD/DA des interfaces procèdent bcp plus rapidement que les valeurs de buffers. Par exemple RME (qui partage cette info pour la BF Pro FS) indique « 5 samples AD, 7 samples DA ». Avec une horloge paramétrée en 44.1KHz, ces 12 samples au total correspondent à seulement 0.27ms. Autrement dit, l'interface audio en elle même n'a besoin (en 44.1KHz) que de 12samples ou 0.27ms pour effectuer les deux conversions. D'autres interfaces ont besoin de plus de temps, mais l'on ne sait pas tjrs combien. Ce qui, entre autres, explique les différences d'efficience entre certaines interfaces audio.
L'on pourrait se dire : « mais pourquoi RME ne nous laisse pas utiliser la BFP FS en 12smp? »
Pour au moins deux raisons évidentes :
La première étant que certaines interfaces, comme la BFP de RME, possèdent des traitements (EQ, Comp, Reverb) à même l'interface, ce qui nécessite du temps de traitement et la deuxième, c'est carrément uniquement par précaution, parce qu’ils savent très bien qu'aucun utilisateur n'utilisera uniquement l'interface en tant que convertisseur audio, mais surtout pour bosser dans un DAW et donc pour ajouter des traitement numérique dans le cours du signal (traitement qui requiert du temps par le processeur du PC). Conséquemment, certains constructeurs limitent la valeur du buffer à 16smp, d'autres à 32 smp et certains même à 64smp. D'une part, probablement parce que certains constructeurs n'arrivent pas à concevoir une interface qui soit capable de faire la conversion AD/DA en deçà de 16smp ou plus (par exemple) et d'autre part parce qu'aucun constructeur n'a intérêt à ce que l'interface produise des glitchs audio (parce que les débutants n'y connaissant rien seront portés à mettre le buffer à sa plus basse valeur).
Donc, si l'on récapitule... ...pourquoi, par exemple (en 44.1KHz), que ma Roland Quad Capture génère 7.6ms et ma Presonus Studio 1810C génère 5.2ms, toutes deux avec leur buffer paramétré à 64smp, alors que la RME BFP FS génère 4.1ms?
- le nombre de smp nécessaire pour que chacune effectue leur conversion AD/DA doit être différent, selon le convertisseur utilisé et selon la maîtrise de l'exploitation de ce dernier au sein de tous les autres composants électroniques de l'interface (P. Ex, RME conçoit leur porpre FPGA),
- la maîtrise du code du pilote ASIO et de la gestion des buffers qui diffère aussi d'un constructeur à l'autre. Certains pilotes étant mieux codés, optimisés,
- parfois l'utilisation d'un buffer interne supplémentaire propre à l'interface (info parfois non communiquée au public. Je crois que c'est le cas de certaines interfaces Focusrite, entre autres),
- la latence que peut ajouter (même si très petite) le protocole de transfert (USB, TB, FW) et ses propres pilotes (qui peut naturellement différer d'un PC à l'autre, selon le type/marque du contrôleur USB, FW, TB, etc.).
Voilà pourquoi l'on ne peut pas se fier ni aux valeurs théoriques concernant les rapports mathématiques entre KHz/sample/milliseconde, ni aux valeurs indiquées par les DAW et/ou les gestionnaires des interfaces, car certains constructeurs omettent parfois (dans un but évident
) d'inclure l'instruction (dans le code) qui doit renseigner le DAW concernant le temps de traitement AD/DA et/ou de certains buffers supplémentaires.
...D'où pourquoi, si l'on veut connaître la réelle latence effective que génère notre interface audio, le seul moyen vraiment fiable à coup sûr, c'est d’utiliser un soft comme RTL Utility en connectant un câble d’une entrée à une sortie de l'interface (l'on peut même tester toutes les entrées/sorties, afin de vérifier s’il y a des différences). Exemple vidéo ici.
Je ne suis pas certain de comprendre ta question dans la mesure où des tests de pistes « non en parallèle » n'auraient aucun intérêt.
Deux types de tests existent :
Soit l'on teste des VSTi (des plugins d'instrument ==> synthés, samplers/ROMplers). Dans ce cas, ben pour tester le maximum d'instance que peut faire jouer simultanément notre machine, ben, faut tous leur faire jouer des notes simultanément, donc oui, n nombre de piste d'instrument en parallèle!
Soit l'on teste des VST (plugin d'FX), et dans ce cas, pour savoir combien d’instances peut gérer notre machine, l'on doit en faire jouer n nombre de piste avec le plus de plugins d’effets possibles — en opération —. Théoriquement, l'on pourrait se contenter d'une seule piste en chargeant plusieurs dizaines de plugins dans la tranche du mixeur correspondante, sauf que certains DAW limitent le nombre de « rack d’effet » pour chaque tranche. D'où pourquoi, même dans ce cas, nous multiplions les pistes avec un fichier audio en lecture, mais pour chacune avec une/des instances de plugins d'effets sur leur tranche respective, ce qui revient à « paralléliser » encore une fois.
Il n'y a pas vraiment d'autre façon que ces deux façons pour tester rapidement ce que peut gérer ou pas un processeur (dans son ensemble, en incluant tous ses cœurs), dans un DAW. Bien sûr, ça ne correspond pas à une utilisation normale, et c'est pourquoi d'ailleurs certains parfois le soulignent, mais utiliser un « vrai projet » pour effectuer le test ne ferait qu'ajouter de la complexité et du temps supplémentaire inutile, car faudrait repérer les passages les plus chargés (où plusieurs pistes, VSTi et VST son en action simultanée), ce qui reviendrait au final au même.
Mais peut-être avais-tu en tête de tester ce que peut gérer un seul des cœurs, dans une même chaîne de traitement uniquement en série? Oui, en effet, ça serait intéressant, mais c'est difficile à mètre en oeuvre, car même si, en principe, ce qui est sur une même tranche n'est pas (ou moins) « parallèlisable », selon les DAW et les plugins (certains ont des options pour activer le multithreading ou non), ce n'est, par expérience, jamais tout à fait le cas à 100%. Il est connu, P. Ex., que d’utiliser des send/Aux/Bus force le traitement en série (sur un même et unique cœur) dans la plupart des DAW, ce qui serait un moyen de procéder, mais en pratique, j'ai souvent observé que ce n'est pas aussi simple ou « catégorique ». Bref, faudrait trouver un DAW, des plugins et donc une combinaison qui semble ne produire qu'un traitement en série. C'est une idée, mais ça me paraît d’avance compliqué (j'avais déjà essayé il y a quelques années, mais dans tous les cas, il y a quand même de l'activité sur plus d’un cœur).
De 37 à 18!!!???
Mais c'est énorme!
En effet, il y a un souci quelque part! Dommage que j'habite outre-mer, j'aurais été faire un tour chez toi. S'il ne s'agit pas d'un « defect » matériel, il y a forcement quelque chose que tu ne fais pas correctement!
Tu installes bien W10 en UEFI/GPT et tu le fais à partir de la derrière image en date (à foutre sur clé USB) fournie sur le site officiel de Microsoft?
Une installation « toute neuve » sur un disque NVMe que tu formates (supprime les anciennes partitions) lors de l'installation?
Et ensuite tu installes bien les pilotes du chipset de ta CM, le contrôleur USB, TB (carte vidéo, son, etc.), etc.?
T'as essayé tout ça, mais avec des réglages « par défaut/optimisés » dans le BIOS? Je veux dire, peu importe le préréglage (il y en a parfois 3 ou 4), mais sans que toi t'aies joué avec les paramètres du BIOS?
Je pense que le commentaire de Deltank, concernant l'OC, émis après le bench de Danbei, est peut-être une confusion de Deltank dans la mesure où Danbei n'a fait « qu'OC » sa RAM pour ses derniers tests. Bref OC la RAM ne produit pas d'amélioration significative selon ce que nous pouvons conclure des tests de Danbei, mais OC un processeur, c'est une autre histoire! Naturellement que ça peut apporter, selon les cas, une amélioration non négligeable. Ça dépend toujours et uniquement de la capacité à encaisser du CPU (Silicon Lottery) et des moyens de refroidissement utilisé!
oui à partir d'une clé us b bootable. en version 21h1. bios remis à defaul uefi. puis réglage de la mémoire en 3600 et en auto pour les latences parce que quand j'utilise les xmp c'est assez CHATAstrophique....
autre réglage dans le bios thundebolt enable (pas le choix) et sécurité user avec acceptation de wondows des connexions necéssaire dans mon cas seulement la carte apollo à ce jour.
par contre suite à la réinstallation hier uad a fait une mise à jour firmware.
maintenant je vais finir l’installation j'en ai encore pour un journée entière pour re télécharger les banks faire les autorisations...
pour lé mémoire l'oc ne sert à rien en dehors des 3600mhz. pour le reste mon test a été faussé par des barrettes en partie défectueuse.
j'ai tout de même tester en 3200 et en 3600 aucune différence avec le ryzen 5900x alors que sur mon 3900x ca faisait une nete différence. d'où la question le test était il juste ou les barrettes ont apporté des résultats qui ne sont pas "réels". mais bon on s'en fout un peu.
oui comme tu dis Darkmoon dommage que tu habites si loin je crois que je t'aurais payé la moitié du billet tellement ça me prend la tete...
ok je ne suis pas un as en informatique et je ne m’alignerai pas contre danbei ou contre toi mais il me semble faire les choses basiques de réinstallation dans les règles de l'art si j'ose dire.
Au fait ça coute combien un billet?
TEST mémoire effectué zero problème.
bon voila vite fait :
1re constatation, j'ai toujours ce problème de latence avec la rme avec le patch x18 pas moyen d'avoir un truc audible en dessous de 256 ....
Par contre, avec la 01v96i ça passe nickel en 32 samples jusqu'à 24 pistes, mais tout est dans le rouge ^^
ça revient à la normale en 1024 (pas vraiment de changement en 128/256/512
doit avoir un truc qui ne tourne pas rond dans le bios
rappel de la config i7 11700kf 16 go ram 3200 cas 16 msi z590 tomahawk, wifi éteint, pas de réseau pas d'antivirus qui tourne et win11
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
Citation de Danbei :
En stéréo, voici un screen shot des réglages :
Ici un lien d'une installation portable de Reaper avec la session, tu peux simplement lancer reaper.exe, configurer l'interface audio et si SGA est dans le chemin des plugins par défaut, ça tournera directement.
https://u.pcloud.link/publink/show?code=XZxatUXZLARgIkJjwUS7K2OHdEsz0RWh0dDX
voici les liens pour reaper test fait par Dan et Darkmoon. j'ai fait exactement le même.
Eric
madamereve
2359
AFicionado·a
Membre depuis 9 ans
Darkmoon
4068
Squatteur·euse d’AF
Membre depuis 20 ans
Citation de Eric :
juste une question les gars avant de commencer. à 64 samples vous êtes à combien de ms?
Ça dépend avec quelle interface. Perso, je possède une Roland Quad-Capture (UA55) ainsi qu'une Presonus Studio 1810c. En 44.1KHz avec le buffer réglé à 64smp, la Roland génère 7.6ms de RTL et la Presonus génère 5.2ms de RTL. En comparaison, la RME Babyface Pro FS génère 4.1ms de RTL pour les mêmes valeurs. La BFP FS est, parmi toute les interfaces USB, celle qui génère le moins de latence à ma connaissance (Sinon une Scarlett 6i6 2nd Gen génère 8ms, une Steinberg UR44 9.5ms, tjrs en 44.1KHz/buffer à 64smp).
Ces valeurs ne sont pas nécessairement celles indiquées par les DAW (valeur indiquée qui peuvent être imprécise), mais les valeurs réelles effectives mesurées avec RTL Utility en branchant un câble audio d'une des sorties vers l'une des entrées de l'interface audio.
Quelques rappels...
En théorie, en 44.1KHz (= 44100 samples/s ou 44,1 samples/ms), 64smp correspond à 1.5ms (44,1 X 1.5 = 66,15smp, d'où le « 64smp » du buffer, un coup « arrondi »). Sauf que lorsque l'on branche un micro et/ou un instrument à notre interface audio, cette dernière doit procéder à une première conversion (Analog to Digital) afin de pouvoir traiter le son numériquement dans le PC, ainsi qu'à une autre au final (Digital to Analog) afin de reconvertir le signal numérique en signal analogique qui est ensuite envoyé, en sortie, sur nos moniteurs/casques.
D'où pourquoi l'on parle de « conversion AD/DA » et pourquoi, si l'on additionne la latence d'entrée à celle de sortie, à ces valeurs (44.1KHz, 64smp), une interface devrait générer, théoriquement, une latence audio total (RTL) de 3ms (1,5 + 1,5). Sauf que les pilotes des interfaces n'ont pas tous la même « efficience » et certaines interfaces peuvent posséder un « buffer » supplémentaire à l'interne.
Mais en réalité, ce n'est pas tout à fait comme ça que ça fonctionne, mais il est nécessaire de débuter par expliquer ça comme ça pour bien comprendre dans un premier temps les rapports entre les fréquences, les samples et les ms.
En fait, quand nous paramétrons le buffer de notre interface en 64smp (P. Ex., mais ça pourrait être en 32smp ou en 128smp), l'interface n'a pas « besoin » de 64smp (ou 1,5ms) pour convertir le signal, car elle peut l'effectuer par « bloc/lot/groupe » encore plus petit. C'est pourquoi nous pouvons choisir un « bloc »(buffer) de 32smp, 48smp voire même 16smp avec certaines interfaces. Le « bloc », le buffer est arbitraire en fait et choisit par nous. La limite étant la plus petite valeur disponible pour le choix du buffer. Mais cette limite est elle aussi un choix arbitraire de la part des constructeurs (nous allons comprendre plus loin), car en réalité le convertisseur (enfin, certains) procède à la conversion encore plus rapidement que la plus petite valeur de buffer disponible.
Autrement dit, les convertisseurs AD/DA des interfaces ont en réalité besoin de moins de temps que la plus petite valeur de buffer disponible pour convertir le signal et ce temps de traitement n'est pas nécessairement partagé au public par tous les constructeurs. Les valeurs de buffers (paramétrable par l'utilisateur), elles, ne sont que des « tailles de lots », des « blocs » de traitement arbitraire, que nous pouvons choisir, et qui ne servent qu'à laisser une marge, un laps de temps au processeur de notre PC dans le cas où, entre la conversion d'entrée et celle de sortie, nous appliquerions un effet numérique dans la « boucle », dans le « trajet » du signal audio.
Et c'est là que certains débutants confondent souvent en croyant que la puissance du processeur « améliore » et/ou influe sur la latence générée par les interfaces audio alors que ce n'est pas le cas du tout. La puissance du processeur n'influe que sur le nombre de traitements numérique (VSTi/VST) pouvant être calculé à l'intérieur d'un laps de temps donné. C'est totalement différent! En principe, si nous ouvrons notre DAW, n'ajoutons aucun traitement et ne touchons à rien, même pas au fader de la piste audio (en écoute de l'entrée Inst/Mic/Line), nous devrions pouvoir utiliser notre interface audio avec la plus petite valeur de buffer disponible sans aucun glitch (et c'est effectivement le cas chez moi), peu importe le processeur.
À ce point, nous devons saisir qu'en réalité les convertisseurs AD/DA des interfaces procèdent bcp plus rapidement que les valeurs de buffers. Par exemple RME (qui partage cette info pour la BF Pro FS) indique « 5 samples AD, 7 samples DA ». Avec une horloge paramétrée en 44.1KHz, ces 12 samples au total correspondent à seulement 0.27ms. Autrement dit, l'interface audio en elle même n'a besoin (en 44.1KHz) que de 12samples ou 0.27ms pour effectuer les deux conversions. D'autres interfaces ont besoin de plus de temps, mais l'on ne sait pas tjrs combien. Ce qui, entre autres, explique les différences d'efficience entre certaines interfaces audio.
L'on pourrait se dire : « mais pourquoi RME ne nous laisse pas utiliser la BFP FS en 12smp? »
Pour au moins deux raisons évidentes :
La première étant que certaines interfaces, comme la BFP de RME, possèdent des traitements (EQ, Comp, Reverb) à même l'interface, ce qui nécessite du temps de traitement et la deuxième, c'est carrément uniquement par précaution, parce qu’ils savent très bien qu'aucun utilisateur n'utilisera uniquement l'interface en tant que convertisseur audio, mais surtout pour bosser dans un DAW et donc pour ajouter des traitement numérique dans le cours du signal (traitement qui requiert du temps par le processeur du PC). Conséquemment, certains constructeurs limitent la valeur du buffer à 16smp, d'autres à 32 smp et certains même à 64smp. D'une part, probablement parce que certains constructeurs n'arrivent pas à concevoir une interface qui soit capable de faire la conversion AD/DA en deçà de 16smp ou plus (par exemple) et d'autre part parce qu'aucun constructeur n'a intérêt à ce que l'interface produise des glitchs audio (parce que les débutants n'y connaissant rien seront portés à mettre le buffer à sa plus basse valeur).
Donc, si l'on récapitule... ...pourquoi, par exemple (en 44.1KHz), que ma Roland Quad Capture génère 7.6ms et ma Presonus Studio 1810C génère 5.2ms, toutes deux avec leur buffer paramétré à 64smp, alors que la RME BFP FS génère 4.1ms?
- le nombre de smp nécessaire pour que chacune effectue leur conversion AD/DA doit être différent, selon le convertisseur utilisé et selon la maîtrise de l'exploitation de ce dernier au sein de tous les autres composants électroniques de l'interface (P. Ex, RME conçoit leur porpre FPGA),
- la maîtrise du code du pilote ASIO et de la gestion des buffers qui diffère aussi d'un constructeur à l'autre. Certains pilotes étant mieux codés, optimisés,
- parfois l'utilisation d'un buffer interne supplémentaire propre à l'interface (info parfois non communiquée au public. Je crois que c'est le cas de certaines interfaces Focusrite, entre autres),
- la latence que peut ajouter (même si très petite) le protocole de transfert (USB, TB, FW) et ses propres pilotes (qui peut naturellement différer d'un PC à l'autre, selon le type/marque du contrôleur USB, FW, TB, etc.).
Voilà pourquoi l'on ne peut pas se fier ni aux valeurs théoriques concernant les rapports mathématiques entre KHz/sample/milliseconde, ni aux valeurs indiquées par les DAW et/ou les gestionnaires des interfaces, car certains constructeurs omettent parfois (dans un but évident
) d'inclure l'instruction (dans le code) qui doit renseigner le DAW concernant le temps de traitement AD/DA et/ou de certains buffers supplémentaires....D'où pourquoi, si l'on veut connaître la réelle latence effective que génère notre interface audio, le seul moyen vraiment fiable à coup sûr, c'est d’utiliser un soft comme RTL Utility en connectant un câble d’une entrée à une sortie de l'interface (l'on peut même tester toutes les entrées/sorties, afin de vérifier s’il y a des différences). Exemple vidéo ici.
Citation de ardier :
...par contre vous ne faites que des tests de pistes en parallele?
Je ne suis pas certain de comprendre ta question dans la mesure où des tests de pistes « non en parallèle » n'auraient aucun intérêt.
Deux types de tests existent :
Soit l'on teste des VSTi (des plugins d'instrument ==> synthés, samplers/ROMplers). Dans ce cas, ben pour tester le maximum d'instance que peut faire jouer simultanément notre machine, ben, faut tous leur faire jouer des notes simultanément, donc oui, n nombre de piste d'instrument en parallèle!
Soit l'on teste des VST (plugin d'FX), et dans ce cas, pour savoir combien d’instances peut gérer notre machine, l'on doit en faire jouer n nombre de piste avec le plus de plugins d’effets possibles — en opération —. Théoriquement, l'on pourrait se contenter d'une seule piste en chargeant plusieurs dizaines de plugins dans la tranche du mixeur correspondante, sauf que certains DAW limitent le nombre de « rack d’effet » pour chaque tranche. D'où pourquoi, même dans ce cas, nous multiplions les pistes avec un fichier audio en lecture, mais pour chacune avec une/des instances de plugins d'effets sur leur tranche respective, ce qui revient à « paralléliser » encore une fois.
Il n'y a pas vraiment d'autre façon que ces deux façons pour tester rapidement ce que peut gérer ou pas un processeur (dans son ensemble, en incluant tous ses cœurs), dans un DAW. Bien sûr, ça ne correspond pas à une utilisation normale, et c'est pourquoi d'ailleurs certains parfois le soulignent, mais utiliser un « vrai projet » pour effectuer le test ne ferait qu'ajouter de la complexité et du temps supplémentaire inutile, car faudrait repérer les passages les plus chargés (où plusieurs pistes, VSTi et VST son en action simultanée), ce qui reviendrait au final au même.
Mais peut-être avais-tu en tête de tester ce que peut gérer un seul des cœurs, dans une même chaîne de traitement uniquement en série? Oui, en effet, ça serait intéressant, mais c'est difficile à mètre en oeuvre, car même si, en principe, ce qui est sur une même tranche n'est pas (ou moins) « parallèlisable », selon les DAW et les plugins (certains ont des options pour activer le multithreading ou non), ce n'est, par expérience, jamais tout à fait le cas à 100%. Il est connu, P. Ex., que d’utiliser des send/Aux/Bus force le traitement en série (sur un même et unique cœur) dans la plupart des DAW, ce qui serait un moyen de procéder, mais en pratique, j'ai souvent observé que ce n'est pas aussi simple ou « catégorique ». Bref, faudrait trouver un DAW, des plugins et donc une combinaison qui semble ne produire qu'un traitement en série. C'est une idée, mais ça me paraît d’avance compliqué (j'avais déjà essayé il y a quelques années, mais dans tous les cas, il y a quand même de l'activité sur plus d’un cœur).
Citation de Eric :
bon ça ne s'arrange pas apres avoir éssayé de faire quelques réglages dans le bios mise à jour du dernier driver thunderbolt, bios... je usi spassé à 18 pistes en 64 samples (3 ms) 24 pistes à 512.... pas terrible donc y a un souci...
De 37 à 18!!!???
Mais c'est énorme!
En effet, il y a un souci quelque part! Dommage que j'habite outre-mer, j'aurais été faire un tour chez toi. S'il ne s'agit pas d'un « defect » matériel, il y a forcement quelque chose que tu ne fais pas correctement!Tu installes bien W10 en UEFI/GPT et tu le fais à partir de la derrière image en date (à foutre sur clé USB) fournie sur le site officiel de Microsoft?
Une installation « toute neuve » sur un disque NVMe que tu formates (supprime les anciennes partitions) lors de l'installation?
Et ensuite tu installes bien les pilotes du chipset de ta CM, le contrôleur USB, TB (carte vidéo, son, etc.), etc.?
T'as essayé tout ça, mais avec des réglages « par défaut/optimisés » dans le BIOS? Je veux dire, peu importe le préréglage (il y en a parfois 3 ou 4), mais sans que toi t'aies joué avec les paramètres du BIOS?
Citation de madamereve :
Pour l'overclocking, je suis pour; pour des raisons de latence et de glitchs, Mon proc ne dépasse jamais 50 degrés en prod....
Je pense que le commentaire de Deltank, concernant l'OC, émis après le bench de Danbei, est peut-être une confusion de Deltank dans la mesure où Danbei n'a fait « qu'OC » sa RAM pour ses derniers tests. Bref OC la RAM ne produit pas d'amélioration significative selon ce que nous pouvons conclure des tests de Danbei, mais OC un processeur, c'est une autre histoire! Naturellement que ça peut apporter, selon les cas, une amélioration non négligeable. Ça dépend toujours et uniquement de la capacité à encaisser du CPU (Silicon Lottery) et des moyens de refroidissement utilisé!
"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
Citation :
Tu installes bien W10 en UEFI/GPT et tu le fais à partir de la derrière image en date (à foutre sur clé USB) fournie sur le site officiel de Microsoft?
Une installation « toute neuve » sur un disque NVMe que tu formates (supprime les anciennes partitions) lors de l'installation?
Et ensuite tu installes bien les pilotes du chipset de ta CM, le contrôleur USB, TB (carte vidéo, son, etc.), etc.?
A propos des partitions. oui j'ai tout supprimé. je repars à zéro ! les partitions de récupération de boot sont remises à zéro. la partition principale même chose. le disque est ainsi clean de chez clean... c'est à cause de ça que je suis dubitatif et ne comprends pas de tels résultats. je boose avec VEP par nécéssité de répartir la puissance de calcul. mais si j'ai reflechis bien un tel pc ne devrait quasiment pas avoir à utiliser d'autres pc pour tourner. oui je fais des choses un peu démesuré dans le sens orchestral (vsti modélisé plutot que samples) mais ça 'est pas par snobiusme mais parce qu'au niveau du jeux pour chaque son on une différence d'interprétation.
ceci dit sgza prouve que mon windows n'est pas conforme à ce que ça devrait être.
dernier point je posais la question de la latence parce que avec 3 ms de temps de latence en thunderbolt avec l'appolo ça fait deux fois moins de temps que d'autres interfaces. j'entends ce que tu dis et je regarderai avec RTL mais ceci dit en 512 j'arrive toujours pas au 38 piste de DAN donc y a un souci...
T'as essayé tout ça, mais avec des réglages « par défaut/optimisés » dans le BIOS? Je veux dire, peu importe le préréglage (il y en a parfois 3 ou 4), mais sans que toi t'aies joué avec les paramètres du BIOS?
oui à partir d'une clé us b bootable. en version 21h1. bios remis à defaul uefi. puis réglage de la mémoire en 3600 et en auto pour les latences parce que quand j'utilise les xmp c'est assez CHATAstrophique....
autre réglage dans le bios thundebolt enable (pas le choix) et sécurité user avec acceptation de wondows des connexions necéssaire dans mon cas seulement la carte apollo à ce jour.
par contre suite à la réinstallation hier uad a fait une mise à jour firmware.
maintenant je vais finir l’installation j'en ai encore pour un journée entière pour re télécharger les banks faire les autorisations...
pour lé mémoire l'oc ne sert à rien en dehors des 3600mhz. pour le reste mon test a été faussé par des barrettes en partie défectueuse.
j'ai tout de même tester en 3200 et en 3600 aucune différence avec le ryzen 5900x alors que sur mon 3900x ca faisait une nete différence. d'où la question le test était il juste ou les barrettes ont apporté des résultats qui ne sont pas "réels". mais bon on s'en fout un peu.
oui comme tu dis Darkmoon dommage que tu habites si loin je crois que je t'aurais payé la moitié du billet tellement ça me prend la tete...
ok je ne suis pas un as en informatique et je ne m’alignerai pas contre danbei ou contre toi mais il me semble faire les choses basiques de réinstallation dans les règles de l'art si j'ose dire.
Au fait ça coute combien un billet?
TEST mémoire effectué zero problème.
Eric
[ Dernière édition du message le 14/11/2021 à 14:45:26 ]
Eric Music Strasbourg
4596
Squatteur·euse d’AF
Membre depuis 17 ans
nicosplash
859
Posteur·euse AFfolé·e
Membre depuis 18 ans
bon voila vite fait :
1re constatation, j'ai toujours ce problème de latence avec la rme avec le patch x18 pas moyen d'avoir un truc audible en dessous de 256 ....
Par contre, avec la 01v96i ça passe nickel en 32 samples jusqu'à 24 pistes, mais tout est dans le rouge ^^
ça revient à la normale en 1024 (pas vraiment de changement en 128/256/512
doit avoir un truc qui ne tourne pas rond dans le bios
rappel de la config i7 11700kf 16 go ram 3200 cas 16 msi z590 tomahawk, wifi éteint, pas de réseau pas d'antivirus qui tourne et win11
https://soundcloud.com/nicosplash
nicosplash
859
Posteur·euse AFfolé·e
Membre depuis 18 ans
madamereve
2359
AFicionado·a
Membre depuis 9 ans
nicosplash
859
Posteur·euse AFfolé·e
Membre depuis 18 ans
- < Liste des sujets
- Charte