réactions à la news L'ordi idéal du zicos : une config dédiée offline?

Citation de Los Teignos :

le projet glitchait et ramait dans tous les sens, mais c'est à une saturation de l'ASIO que nous avions affaire, pas aux limites du processeur.

Partiellement faux : Les 2 sont liés.

Je ne sais pas si tu t'en souviens, mais il y a quelques années, la jauge Asio de Cubase se nommait "Cpu".
Je pense que Steinberg l'a renommée pour tenir compte du fait que comme tu le dis, la communication avec l'interface audio a de l'importance, mais ce n'est pas pour ça que le Cpu n'en a plus.

Sur les stations que je monte, avec un buffer de 512 (voire 256), je peux arriver à utiliser presque l'intégralité du Cpu sans craquements, tant et si bien qu'un click sur le bouton stop ne réagit pas tout de suite tellement le processeur est occupé.

Ensuite, si on diminue la latence, alors effectivement la portion de Cpu utilisable avant les craquements diminue petit à petit. C'est exactement ce qu'on voit ici :

(Les tests datent un peu, mais les courbes restent peu ou prou de la même forme aujourd'hui)

Mais même si à la latence la plus basse on ne peut pas utiliser l'intégralité de la puissance du processeur, on voit très bien qu'avec un processeur plus performant, on peut tout de même effectuer plus de traitements temps réel.

Toi qui vient du monde du jeux vidéo, je suppose que tu connais très bien les termes "Cpu limited" ou "Gpu limited".
En audio, le terme "Cpu limited" existe bien : On se retrouve dans la situation où le cpu ne peut plus faire plus, lorsque la latence est élevée, ET que l'interface audio n'est pas trop mauvaise.

Lorsqu'on diminue la latence, l'efficacité de l'interface audio entre alors à son tour en jeu. La capacité de traitement audio va donc dépendre de la puissance cpu ET de l'efficacité de l'interface audio. Les deux sont intrinsèquement liés, un peu comme couple et puissance.
On peut voir dans le graphique ci-dessous que pour un même cpu, les performances en audio ne sont pas les même selon les interfaces.

Bien entendu, utiliser un ordinateur très puissant avec une interface audio inefficace est un non sens car une bonne partie des ressources restent inutilisées.
Mais augmenter la puissance Cpu tout en gardant la même interface (une correcte) permet d'utiliser plus de traitements avant que les craquements apparaissent.



Hmmmm, je m'éloigne un peu du sujet.... :-)

En fait, dans le cas présent, on s'en fiche un peu, il faut vraiment le prendre comme un score tel que le donnerait un test tel que 3dmark ou autre. Le score varie en fonction de la latence.

Pour détailler tout de même, il s'agit du test dawbench avec les plugins Reaxcomp. Il y a 4 pistes audio de musique, ainsi que 40 pistes audio stéréo sur lesquels on active le plus de plugins possible jusqu'à ce que ça commence à craquer. Le nombre de plugins actifs sans craquement devient le score qu'on retrouve sur l'axe des ordonnées.

Sur les abscisses, le round trip latency est la latence totale (entrée + sortie) mesurée.

Les 4 points qu'on voit sur la courbe de la digiface correspondent au nombre de plugins que j'ai pu activer pour les buffers 256, 128, 64 et 32.

Je parle de score car le nombre de plugins en lui même n'a pas d'importance. Il suffit de remplacer le compresseur ReaXcomp par autre chose pour que les valeurs ne soient plus les même, mais les courbes resteraient identiques et les écarts aussi.

Le graphique que j'ai dans ma feuille excel comporte beaucoup plus d'interfaces audio, mais pour l'exemple je n'en ai conservé que 3 avec des résultats très différents.

Pour une latence totale de 4,4ms, avec une Emu 1212m pci, j'ai un score de 96 plugins

Pour la même latence, avec une Rme Digiface, j'ai un score d'environ 160 plugins, c'est à dire 70% de plus !

Dis autrement, avec une 1212, pour obtenir la même puissance de traitement à 4.4ms qu'avec la Rme, il faudrait un ordinateur 70% plus puissant !!

Citation de : Los Teignos

Par ailleurs, les différences qu'on observe ici entre la Mbox d'un côté, et la Digiface et l'E-MU de l'autre ne sont elles pas plutôt conditionnées par l'interface PCI d'un côté et USB de l'autre?

 Partiellement, car si tu compares la 1212m pci et la Mbox, on voit que si l'Emu peut descendre plus bas en latence, elle n'est pas pour autant meilleure que la Mbox en haute latence. Et si la Mbox permettait de réduire son buffer sous la valeur de 128, elle resterait peut-être au dessus de la Emu.

Bon, j'ai volontairement choisi ce qui se fait de pire en Pci, la plupart des autres interfaces en Pci ou Pci express ont des résultats très proches de ceux de la Digiface, et sont un cran au-dessus des interfaces Usb/Firewire

Au sein des groupes IEEE1394 et USB, c'est assez variable. Regarde ça :

Les Rme en Firewire (Fireface 400) et en Usb (Babyface) ont des résultats assez proches, alors que la Mbox 2 Pro qui est en Firewire, bus de connexion censé être supérieur à l'usb, est derrière.

Tout comme le graphe précédent, je n'ai pas tout placé toutes les courbes que j'ai, et certains modèles ont des résultats bien inférieurs à ce qu'on voit ici.

Donc, il n'y a pas vraiment de règle, cela dépend du modèle de l'interface.

J'oubliais : Tous ces résultats concernent du matériel fonctionnant avec Windows.

Citation de : ardier

et la j'ai une vrai question comment peux t-on déceler le maillon faible lors d'un pic de charge ASIO?

 Si le pic n'est pas lié au séquenceur, à l'interface audio, ou à un plugin, alors des logiciels tels que DPC Latency Checker et Latencymon peuvent t'aider. (Si tu utilises Windows, je ne connais pas d'équivalent pour OsX)

Citation de : skarabee.nc

Donc, du coup, USB/Firewire, même combat? J'imagine là aussi que cela dépend des marques et des modèles. Pourquoi certains fabriquants ne permettent pas d'abaisser les buffers au delà d'une certaine valeur? Uniquement par sécurité?

 Oui c'est ça, excepté pour le Pci-e, il ne faut pas se fier au type de bus de communication pour juger de l'efficacité d'une interface. Seul des tests comme ceux que je fais permettent de vraiment le savoir. Je teste tout ce qui me passe entre les mains, mais beaucoup n'ont jamais atterri sur mon bureau.

J'ai demandé à l'importateur français pourquoi les nouveaux produits Avid en Usb ne permettaient pas de descendre plus bas en latence, mais ils n'avaient pas la réponse. Cela peut être un choix marketing pour différencier les modèles Usb des modèles Firewire, un choix technique parce que ça ne marche pas bien sur des latences plus faibles, ou tout autre chose.

Les mecs qui développent des freeware sont, pour beaucoup, des militants de l'open source, et, de ce fait, s'ils doivent développer pour une plateforme, ce sera d'abord sur linux ou équivalent, par conviction.

Les freeware windows sont nombreux parce qu'une écrasante majorité d'utilisateurs sont sur ce système, et qu'il reste relativement ouvert par rapport à l'écosystème apple.

Perso si je donnais de mon temps libre pour développer sur une plateforme, je pense que la dernière sur laquelle je ferai un portage serait la plateforme apple compte tenu de la politique de fermeture qu'ils pratiquent et de la manière dont ils rincent les éditeurs qui veulent profiter de l'appstore...

En tout cas c'est le discours que j'entend tout autour de moi chez les programmeurs que je fréquente...

Citation de : solo84

Perso je suis un adepte du dual-boot, mais pas forcément pour internet: surtout pour garder une config "clean", c'est  dire une config où la base de registre ainsi que les fichiers type hiberfil.sys...etc ne deviennent pas énormes à force d'installations+désinstallations de logiciels, plugins, freewares en tout genre...

 

Donc W7 64 est installé sur 2 partitions dont une seule ne peut être visible au même moment, le choix se faisant au démarrage. J'utilise GAG, un freeware qui s'installe dans le MBR, un secteur du SSD qui se situe avant les systèmes d'exploitation, donc même en cas de plantage total aucun risque de ne plus démarrer...

 Pareil,GAG et des systèmes qui cohabitent : Win7 - 64, FEDORA CCRMA, Ubuntustudio, Tangostudio... Les Linux font du temps réel et de la MAO, Windows fait du traitement de texte (encore que, Linux aussi bien), de l'internet, du pilotage de périphériques qui n'ont pas de pilotes sous Linux (Merci Line 6 et ses trucs propriétaires à mortquitue).

J'ai cependant remis en service un vieux laptop en 32 bits, sous XP, pour utiliser la version gratuite de EWQL Symphonic Orchestra. Ballot, je n'avais pas pensé à télécharger la version X-64 à l'époque, n'ayant pas de machine en 64 bits.

Et un ordi de bureau sous Linux seul, pour faire uniquement de la MAO.

Et j'ai des images disques aussi de tous mes systèmes, non pas tant pour remettre quand cela ralentit, mais pour me garantir contre un plantage ou un virus quelconque.

Et aussi un disque dur amovible, qui me permet de passer du boulot à la maison, d'une machine à l'autre, d'un système à l'autre, les fichiers dont je peux avoir besoin.

Avec tout cela, je suis content, j'ai une super configuration, il me suffit de 30 s pour passer mes claviers de l'un à l'autre en midi ou en audio, de 2s pour brancher une guitare ou un micro, je devrais passer mon temps à faire de la musique.

Si seulement je n'avais pas à bosser par ailleurs, nettement plus que les 35 h,  pour vivre et me payer mon matos    ! !