Discussion :

[luckyvae]

Bonjour tout le monde

Je suis en train de créer un petit jeu, et j'aimerai pouvoir y incorporer du son. J'ai donc une petite librairie qui me permet de charger un fichier son depuis le disque, et pour le jouer, je dois faire une boucle qui lit le fichier et le joue.
Pour jouer plusieurs sons en même temps, je dois donc faire plusieurs processus?

Si oui, j'imagine qu'une solution envisageable est la suivante:
je définis le nombre maximum de sons pouvant être lu en même temps, je crée le nombre processus correspondant, et lorsque je dois jouer un son je le donne au premier processus en attente que je trouve. Si il n'y a aucun processus en attente, j'attends qu'il y en ai un qui se libère.

Si il y a moyen de faire autrement, je suis preneur...

PS: j'ai délibérément omis de dire avec quel langage je travaille pour pas que vous me répondiez "C'est simple utilise la librairie XXX"

[Le Barde]

En fait tout dépend du niveau de granularité de ce que tu veux faire pour gérer les sons. À un niveau "bas", tu as OpenAL (que je ne maîtrise pas).

Ton moteur audio servirait à jouer des sons uniquement ou à intégrer une logique en plus ? Parce que tu as le module audio de la SFML qui fonctionne très bien. Pour répondre à ta question, il crée un thread pour chaque son joué. Mais regarde ici un exemple d'utilisation, ça pourra peut-être te donner des idées : module audio SFML.

[luckyvae]

Mon moteur audio serait destiné à être utilisé dans un jeu, mais en gros, tout ce qui se passerait, c'est "joue tel son", "joue tel musique", "met le volume à X" donc je pense que je vais faire un processus par son.

Mais j'hésite entre les deux politiques suivantes:

- les processus attendent pour pouvoir jouer quand ils n'ont rien à faire
- les processus sont crées, jouent un son puis meurent

qu'est-ce qui pourrait être mieux?

[Djakisback]

Salut,
j'ai fait ça en Java récemment. Personnellement j'utilise la méthode 2 avec des threads et ça fonctionne très bien. J'ai pas tenté la méthode 1. Si je comprends bien ta question, c'est de savoir si c'est plus efficace de laisser tourner des threads qui servent à rien que d'en créer/détruire de nouveaux à chaque fois.
Si quelqu'un a la réponse ça m'intéresse aussi. A priori cette fois, la réponse va dépendre du langage utilisé (en plus du contexte : nombre de threads créés au départ, fréquence des appels, etc). (Ca va aussi dépendre de si t'utilises des threads ou des processus ^^).

[moldavi]

Bonjour.

Je vais peut-être dire des bêtises, mais il me semble que pour un jeu vidéo, un moteur audio fonctionne de cette façon :

- pour les sons brefs (genre une explosion), le fichier est placé directement dans le buffer de la carte audio. Si la place est limitée, il faut créer un pool de son "bref" et faire circuler les sons à la demande entre le pool et la carte. En optimisant, on pourrait charger/décharger les sons lors d'un changement de niveau par exemple. Ici pas besoin de thread, faut juste dire à la carte audio quel buffer jouer.

- pour les sons plus "longs", qui ne peuvent pas être positionnés dans la carte audio ou à cause de leur complexité (5.1), là effectivement, il faut "threadé" la chose. Mise à part si tu as cinquante sons de ce type, un chargement/mise en pause suffit. Le flux est streamé, lorsqu'il est en pause tu as une taille fixe de l'ensemble, donc facile de voir si c'est mieux de garder en mémoire ou s'il faut décharger/recharger. Toujours pareil, une optimisation serait de ne garder que les morceaux en pause pour un niveau, puis de décharger/charger pour le niveau suivant. Evidemment ce dernier point implique que dans ton moteur de son, il y ait la possibilité de déterminer des pools de morceaux, dans ce cas le moteur pourra lancer rapidement un son de tel pool.

Par exemple, l'utilisateur de ton moteur a 3 morceaux longs pour le niveau 1 et 5 autres morceaux longs pour le niveau 2. Tu lui permets de créer 2 pools de musiques. Au niveau 1, il charge le pool numéro 1 (les 3 morceaux). Ces 3 morceaux seront disponibles sans création/destruction de thread. Au niveau 2, il dira a ton moteur de décharger le pool numéro 1 puis de charger le pool numéro 2, etc... Si un morceau fait parti des deux pools, pas besoin de le décharger...

Ton moteur audio à la responsabilité de dire quand l'utilisateur exagère, si par exemple il voudrait utiliser 300 morceaux de musique (bon là c'est moi qui exagère, mais il faut penser à tout ça). Bien sur ce système peut s'appliquer au son plus court qui serait positionnés directement dans les buffers de la carte, avec un petit roulement entre chaque niveau.

Et pour faire pro, mais je ne voudrais pas te décourager, ton moteur devrait même connaître les limitations hardware (carte audio, processeur graphique, mémoire vive, etc...), qui te permettrait de déterminer jusqu'à combien de morceaux de musiques, ton moteur pourra fonctionner correctement.
Par exemple, pour les sons que tu places directement dans le buffer de la carte audio, et bien certaines cartes ont plus de mémoire que d'autres, donc tu pourras connaître le nombre de son que tu peux y caser, ou si un pool est nécessaire, etc...

[Ti-R]

OpenAL permet justement de manipuler les différents buffer, et d'avoir une gestion bas niveau du son.

De plus, couplé à d'autres bibliothèques on peut faire de l'EAX (normal la bibliothèque vient de Creative)

Donc cela pourrait répondre à tes besoins.

Sinon regarder irrKlang, qui semble très bien aussi.