OpenAL sur Mac OS X: Réglage AL_SAMPLE_OFFSET ne fait rien

Question

au travail, nous sommes incapables d'utiliser alSourcePause() pour suspendre les sons, et dans tous les cas, nous pourrions vouloir démarrer le son avec un décalage.

Nous effectuons un "resume" en faisant alSourcei(this->sourceId, AL_SAMPLE_OFFSET, this->sampleOffset); avec un offset d'échantillon que nous avons récupéré avec alGetSourcei(). Nous avons essayé d'utiliser AL_SEC_OFFSET, AL_BYTE_OFFSET et AL_SAMPLE_OFFSET - en vain. Nous avons lu que la source sonore doit être dans l'état "initial"; recréer la source et attacher le tampon, puis tenter de sauter aussi n'a pas aidé.

La modification du tampon pour ignorer AL_BYTE_OFFSET n'est pas une solution car cela complique la mise en boucle.

Les sons en continu sautent sur des machines plus lentes; nous avons du mal à mettre en place un jeu multithread.

Puisque nous sommes sur un calendrier serré, quelle est la meilleure façon d'ignorer une partie d'une source sonore simple sur OpenAL sous OS X? Le code source est disponible à our Sourceforge repository.

Answer 1

J'ai récemment rencontré le même problème dans notre moteur de jeu sous OS X (10.6.8). Nous avons effectué les étapes suivantes lors de la reprise de la lecture d'un tampon statique avec un échantillon donné offset, dans cet ordre:

alSourceQueueBuffers(mSourceId, 1, mBufferId); 
alSourcei(mSourceId, AL_SAMPLE_OFFSET, mSampleOffset); 
alSourcePlay(mSourceId); 

La source a été arrêté avant que, et tous les tampons ont été unqueued. Selon les spécifications de la version 1.1, il devrait être possible soit

1. de spécifier le décalage du tampon lorsque la source est à l'état arrêté; ici, le décalage est censé être appliqué lors de l'appel alSourcePlay() suivant, ou
2. spécifier le décalage sur une source en cours de lecture, ce qui devrait entraîner un passage immédiat à la position désirée.

(Voir la section 4.3.2 des spécifications officielles à http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm)

Inverser les deux derniers appels dans la séquence ci-dessus (réglage du tampon de décalage après l'émission de l'appel alSourcePlay()) a fait l'affaire en notre cas. Techniquement, cela devrait être une manière parfaitement valable d'aller; Toutefois, si le fil audio est interrompu entre ces deux appels pendant trop longtemps, cela peut entraîner des problèmes de fonctionnement.