Gain de performance entre AU et QC.
orfait
Membre
Bonjour,
Depuis quelques jours, je me pose une question assez bête mais dont je ne trouve pas réponse facilement.
Je commence par le commencement :
J'ai fait une application qui devra à terme faire ceci :
- Envoyer, via 2 threads différents, des données à 2 interfaces USB
- Afficher une animation QC en plein écran sur un écran secondaire
- Analyser le son pour modifier les données envoyées aux interfaces
Bref, actuellement, tout est presque fini sauf l'envoi des données par USB (mais ce n'est pas un problème puisque j'ai déjà les classes de faites dans un autre projet).
Mon problème se situe dans l'analyse du son. J'avais besoin tout bêtement d'avoir des données du spectre du son entrant dans l'entrée choisie dans les préférences système. Donc pour faire ça tout simplement, j'ai réalisé une animation QC qui affichent un spectre et le peak et j'ai aussi ajouté en javascript le code pour détecter les beats de la musique.
Tout fonctionne bien à un détail près. Si je met une animation trop complexe en plein écran (ce qui fait que j'ai deux animations QC qui tournent), mon analyseur est particulièrement ralenti et inutilisable !
A savoir que ces animations trop complexes font même ramer le dock.
Ma question est donc : est-ce que je peux utiliser un plugin AU pour l'analyse du spectre et le renvoi des données de beat vers l'appli Cocoa ?
Si oui (ce que je pense), est-ce que je vais avoir une meilleure réactivité ?
Merci !
PS (les oublis):
-L'animation QC en plein écran : je n'utilise pas d'environnement OpenGL mais un simple NSView avec l'astuce du plein écran publiée ici-même.
-Je n'ai pas fait de tests avec un plugin AU car je ne n'y connais absolument rien. Donc avant d'apprendre, je cherche à savoir si j'y gagne (sinon, j'apprendrai plus tard).
-J'ai donné mon appli à mon père qui est sur macbook, elle ne démarre même pas donc je vais aussi passer dans la zone de test.
Depuis quelques jours, je me pose une question assez bête mais dont je ne trouve pas réponse facilement.
Je commence par le commencement :
J'ai fait une application qui devra à terme faire ceci :
- Envoyer, via 2 threads différents, des données à 2 interfaces USB
- Afficher une animation QC en plein écran sur un écran secondaire
- Analyser le son pour modifier les données envoyées aux interfaces
Bref, actuellement, tout est presque fini sauf l'envoi des données par USB (mais ce n'est pas un problème puisque j'ai déjà les classes de faites dans un autre projet).
Mon problème se situe dans l'analyse du son. J'avais besoin tout bêtement d'avoir des données du spectre du son entrant dans l'entrée choisie dans les préférences système. Donc pour faire ça tout simplement, j'ai réalisé une animation QC qui affichent un spectre et le peak et j'ai aussi ajouté en javascript le code pour détecter les beats de la musique.
Tout fonctionne bien à un détail près. Si je met une animation trop complexe en plein écran (ce qui fait que j'ai deux animations QC qui tournent), mon analyseur est particulièrement ralenti et inutilisable !
A savoir que ces animations trop complexes font même ramer le dock.
Ma question est donc : est-ce que je peux utiliser un plugin AU pour l'analyse du spectre et le renvoi des données de beat vers l'appli Cocoa ?
Si oui (ce que je pense), est-ce que je vais avoir une meilleure réactivité ?
Merci !
PS (les oublis):
-L'animation QC en plein écran : je n'utilise pas d'environnement OpenGL mais un simple NSView avec l'astuce du plein écran publiée ici-même.
-Je n'ai pas fait de tests avec un plugin AU car je ne n'y connais absolument rien. Donc avant d'apprendre, je cherche à savoir si j'y gagne (sinon, j'apprendrai plus tard).
-J'ai donné mon appli à mon père qui est sur macbook, elle ne démarre même pas donc je vais aussi passer dans la zone de test.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Quartz Composer c'est le top parce que c'est facile à faire, en branchant les briques toutes faites les une aux autres. Mais faire du plus bas niveau (en utilisant directement les plugins AU) y'a quand même de grosses chances pour que ce soit plus direct et donc aussi plus rapide (et plus spécialisé, tu utiliseras un code dédié à ce que tu veux faire, pas un truc générique sachant faire plein de trucs et dont tu n'utiliseras que ce qui t'intéresse).
Après, je suis loin d'être spécialiste, n'ayant jamais utilisé les plugins AU. Mais je suppose que ce que tu veux faire (qui se résume à une analyse spectrale genre Fourier) étant la base, c'est un des trucs les plus optimisés que tu pourras trouver dans les AU.
Utiliser une NSView n'est pas une très bonne idée, parce que le rendu est fait en mémoire (=fait en mémoire vidéo, puis copié dans la mémoire centrale, puis affiché (=copié dans la mémoire vidéo). Pour avoir les meilleures performances avec OpenGL, il faut travailler en plein écran (ce que tu fais), en dessinant dans une NSOpenGLView. Autrement, tu as ce "buffering" qui fait perdre beaucoup de temps. Essaie pour voir de changer le mode de buffering de ta fenêtre (dans Interface Builder). Dans QC, compare ton animation QC en mode fenêtré et en mode plein écran, la différence de vitesse doit être flagrante.
Pour info la GLUT (dont le code est livré en exemple par Apple), utilise la classe NSOpenGLView, c'est donc qu'au niveau performances, ça colle.
Autrement, tu peux effectivement utiliser les AudioUnits dans un code écrit en ObjC, mais je ne crois pas que tu puisses obtenir beaucoup de gain de ce côté, c'est vraiment au niveau du graphisme.
J'ai codé un peu en OpenGL, et je peux te dire que Quartz Composer est vraiment plus lent qu'un même programme codé à la main. J'ai pu le constater avec un programme simple qui affiche un cube, mais je ne peux pas te donner la raison précise (textures non chargées dans la mémoire vidéo?)
Peux-tu donner d'avantage de détails sur ton animation, pour me donner une idée de la complexité?
Mais je suis très attaché aux animations QC puisque mon logiciel est destiné à évoluer facilement selon les besoins des utilisateurs (on place une animation qtz dans un dossier de l'appli et hop, ca roule).
Actuellement, j'ai créé un QCView et j'ai ce code pour la passer en plein écran :
Notes :
- ecran est un outlet vers une liste déroulante pour choisir sur quel écran on passe en full
- quartz est un outlet vers le QCView de l'animation
(pas frapper si le code est pas bien
EDIT : après test avec le player Quartz Composer en milieu opengl, les performances sont encore pire ! Le QCView redimensionné fonctionne mieux, ce qui me surprend beaucoup.
Petit détail : je parle des performances du reste de l'appli et de l'OS, pas de l'animation.
En utilisant AULab et en chargeant un AU ne faisant qu'afficher le spectre, c'est complètement saccadé dès que je lance la plus lourde de mes animations QC.
D'ailleur, c'est la totalité du système qui saccade et le plus surprenant à mes yeux : charge CPU à 20% en moyenne.
Je me demande si je ne devrais pas plutôt poster dans le forum sur quartz...
As-tu essayé de changer le backing comme je te l'écrivais hier?
Essaye avec NSBackingStoreNonretained.
Dans ce cas, le rendu est fait directement par la carte graphique, en incrustation, et ça doit tourner plus vite.
L'analyse spectrale ne doit pas prendre beaucoup de temps, ça marchait déjà très bien sur mon vieux Performa 6320 en 97, c'est vraiment sur les animations.
Je te demandais à quoi ressemble les animations parce que c'est souvent optimisable: réduit la taille des textures, n'utilise que des textures dont les dimensions sont des multiples des puissances de 2. Il me semble qu'il existe une option dans la configuration des boiboites QC pour demander la mise en mémoire vidéo d'une texture. C'est très très important pour les performances.
J'insiste là -dessus parce que CQ ne génère pas de formes très compliquées, donc il y a peu de polygones à afficher et d'optimisation de ce côté-là .
Mais bon, c'est vrai qu'on ne sait pas trop ce que fait QC dans sa tambouille interne... Mais ton ordi fait tourner Quake 4, alors c'est pas les 3 polygones d'une animation QC qui devraient être si lourdes que ça.
J'ai modifié en mettant "NSBackingStoreNonretained". La différence n'est pas visible (et surtout insuffisante si il y en a une).
Mes animations QC n'utilisent pas de texture dans la majorité des cas, mais ce qui fait ramer c'est surtout les particules (en blending = add)... avec un total de particules oscillant entre 600 et 3000 (avec un replicate in space).
J'ai mis un des effets qui fait tout ramer en fichier joint. Il faut un signal sur l'entrée de la carte son pour qu'il fonctionne.
[Fichier joint supprimé par l'administrateur]
Déjà sur mon iMac G5, on ne peut pas dire que ça ralentisse beaucoup la machine. Elle est un peu moins réactive, mais c'est tout, les autres logiciels restent utilisables.
ça m'a aussi permis de me rendre compte qu'il n'existe pas d'AU livrée avec Mac OS pour analyser le spectre (cf http://developer.apple.com/documentation/MusicAudio/Conceptual/CoreAudioOverview/index.html). Et comme QuartzComposer propose le spectre, je ne sais pas comment il fait. Peut-être utilisent-ils les routines de FFT dispos dans l'Accelerate Framework.
Afficher les particules ne doit pas être si compliqué pour la carte graphique. ça ne fait que 450 particules (900 polygones). Le rendu est fait dans la mémoire vidéo, et ce rendu est recopié 3 fois par le replicate in place.
En relisant tes messages, finalement, je ne sais pas à quel genre de performances tu t'attends, mais chez moi (je sais c'est pas complet), ça tourne plutôt bien, je trouve.
P.S.: Il est sous quelle version d'OS X ton père? ça ne marche que sous 10.4.
Sinon, pour mon appli, quand je vois la perte de performance, je trouve que c'est insupportable. Si je lance un flash sur un beat musical et que j'ai 0,5s de retard, c'est complètement ???
Après, je voudrais bien savoir si même avec un affichage foireux, un plug AU tourne correctement.
Moi, quand j'utilise cette animation correctement (c'est à dire l'écran est rempli de particules... ca déborde de partout), même le dock rame (l'effet d'agrandissement). Alors soit on n'a pas la même notion de "ramer", soit j'ai un autre problème...
(j'oublie de dire que ça rame surtout en bi-écran. J'ai un macbook pro tout de même, je trouve ça limite)
Tout d'abord, il faudrait voir si le reste du soft est correct donc je passe dans la zone de Debug : ici
Et puis ensuite, ce topic reste d'actualité pour chercher une solution sur les perfs de "mes" animations et je remercie encore les participants pour leur aide.