probleme de performances évident

[olof29]

Frontieres (tout comme Borderlands) a de serieux problemes de performances :
au dela de 3 clouds ou de 3 voix de polyphonie midi, ou de 24 grains dans un cloud, c'est les xruns quasi garantis, et ce meme sur un machine avec 8Go de memoire, et 512 en buffer pour jack en 44000.

il ya donc surement des choses faisables pour ameliorer ça, mais ce n'est pas dans mon domaine de competance actuel

[olof29]

j'ai un peu exploré la bête, et j'en viens à la conclusion que le systeme de production du son dans les grains est beaucoup trop gourmand, et génère même des soucis de "rémanance" du son :

• tout est calculé à chaque tour de boucle de generation du son pour chaque grain, y compris l'exploration de tous les samples pour voir s'il est dedans... je pense que c'est de là que vient le probleme de performance.
• il serait préférable, selon moi, de calculer tout cela au moment de la création du grain et de le recalculer au besoin si celui ci change de place, ou si on deplace un sample, ou toute autre chose qui agit sur les grains. et de n'avoir qu'à lire les "waves" des grains dans la boucle de generation de son.

[jpcima]

Apparemment le passage de 2 à 16 canaux a un impact tout à fait considérable, il faut examiner ce qui se passe à ce niveau-là.

D'après le profiling, la très vaste majorité du temps de calcul est consommée par Grain::nextBuffer (ce qui paraît tout à fait logique)
C'est cette procédure qui est le point sensible et qui doit être optimisée au mieux possible.

Elle se structure d'une manière imbriquée comme ceci :

• * pour i = 0 → nombre de trames à calculer
• ** pour j = 0 → nombre d'échantillons actifs
• *** si l'échantillon n'est pas terminé
• **** si l'échantillon est stéréo/mono
• *** pour k = 0 → nombre de canaux

Idées

1. Ceci est inefficace en terme de cache de données, car chaque itération va passer successivement d'un échantillon à un autre. Ce serait bien mieux si une solution permettait d'intervertir les boucles i et j.
2. Pour cela il faut voir ce que l'on doit faire avec la boucle k. Sans savoir trop ce que ça fait a priori, j'observe que ça parle de mono et stéréo. Est-ce que c'est nécessaire de répéter cette partie autant de fois qu'il y a de canaux ?
   Est-ce que le clip est véritablement nécessaire ici ? j'en doute. On peut faire cela tout à la fin du traitement. Voire pas du tout. C'est en nombre flottant, le système audio sous-jacent peut s'en occuper.
3. On peut faire sauter le switch ****. Cela fait un branchement en moins, que l'on peut réaliser en faisant duplication du corps de fonction, une fois que la boucle j est réordonnée pour être mise en premier. On pourrait faire ça proprement avec un template <unsigned int C>, où la constante C désigne le nombre de canaux de l'échantillon (1 mono/2 stéréo).

[olof29]

en fait , le processus ne s'arrete pas dans le nextbuffer du cloud, mais invoque le nextbuffer de chaque grain, qui lui meme explore tous les samples à chaque fois.

j'etais pour ma part en train d'explorer l'idee suivante :

• produire en amont, hors boucle nextbuffer, un echantillon de son correspondant à ce que le nextbuffer des grains produit, suffisamment long pour correspondre à un bouclage du son (cela pose un probleme de taille si on a des vibratos longs, c'est là que le butte pour le moment)
• alleger considerablement du coup le nextbuffer de cloud qui se contenterait de lire cet echantillon en entretenant un curseur de bouclage sur celui ci.
• chaque modification des parametres du cloud entrainerait un recalcul de cet echantillon, hors boucle de lecture (avec un echange en fin de recalcul , sous protection du verrou memoire de scene)
• pour le moment tout cela n'est que theorique dans ma tete, et j'ai une crainte sur la faisabilité de la chose, non seulement à cause de cette longeur d'echantillon, mais aussi sur la perte du temps reel dans les changements sur les parametres d'un buffer, et j'envisageais de laisser la methode actuelle et d'introduire un parametre supplementaire qui permettrait de basculer d'une methode a l'autre pour un cloud.

pour ce qui est de la perte de performance en 16 canaux, elle n'est effective que si on laisse le son en 16 canaux.
des qu'on le met en stereo sur les canaux 4 et 5 par exemple, cela revient au meme qu'avant.

pour ce qui est des imbrications de boucles, j'avoue que j'ai planché dessus sans vraiment saisir le sens de tout ça, et ai laissé tomber cette piste, donc toute amélioration à ce niveau est bienvenue (et peut etre serait ce suffisant)

[olof29]

ou en es tu des suggestions que tu avais faites ici ?
je pense que tout le corps de la production sonore est à revoir à la fois pour les performances et pour l'histoire de retard du son (remanance).
serait ce une bonne idée que les grains contiennent les sons, mis à jour dans leur positionnement visuel ?

[jpcima]

Ça n'a pas dépassé le stade de suggestion pour l'instant.

Je ne pense pas que mettre en cache un segment d'audio pour le rejouer en boucle soit vraiment une solution réalisable.
A supposer que ça soit possible de mettre en cache des segments d'audio, qui sont invalidés par le paramétrage dynamique de scène, cela veut quand même dire que tu vas avoir : des cycles rapides (le cache est prêt), ou des cycles lents (pas encore prêt)

Ça implique que tu as toujours à faire de temps en temps au pire cas en complexité de calcul, qui reste la même. En contrainte temps réel, c'est une mauvaise chose.

[olof29]

ok, je ne vais donc pas continuer de reflechir à cette piste, ça m'arrange même en fait parceque je me heurtais à pas mal de problèmes logiques