OpenAL: alBufferData renvoie AL_INVALID_VALUE même si les variables d'entrée * ont l'air * OK?

Question

Donc, je construis un décodeur IMA ADPCM fileté en streaming de données audio à OpenAL (voir ci-dessous pour une description courte) mais j'ai eu des problèmes.

Un de mes problèmes est que parfois mon appel à alBufferData:

alBufferData(*bufferID, format, pcmData, sizeInBytes, bitRate);

retours AL_INVALID_VALUE même si, lors de la vérification des paramètres qu'ils regardent, par exemple, comme ceci:

bufferID='109770616', format='AL_FORMAT_STEREO16', dataPtr='109754188', sizeInBytes='8164'

Des indices, quelqu'un? Le son réel est joué en quelque sorte de bégaiement quand cela se produit, et l'erreur se produit généralement ~ 10 fois de suite (sur le même son). Il arrive aussi souvent quand je commence à plusieurs reprises le même son (par exemple lors de la prise de courtes rafales avec un LMG ...;))

visite rapide et simplifiée du streaming module décodeur-chose

Comment un son est joué:

1. Un son est déclenché.
2. Une valeur bufferSize d'audio est décodée et le reste est mis en file d'attente pour un décodage ultérieur.
3. OpenAL est déclenché pour lancer la lecture du son.

Le décodage/boucle en continu

1. Pour chaque son mis en attente pour le décodage, décoder une valeur de bufferSize audio.
2. L'audio décodé est ajouté à un alBuffer (voir l'appel ci-dessus) avec le bufferID approprié.

Answer 1

Si ce n'est pas trop tard, je vais vous dire les problèmes similaires que j'avais avec BufferData et voici comment je l'ai réparé. Bien, gardez à l'esprit, je ne connais pas les détails de votre programme fileté.

valeur non valide est renvoyée pour un certain nombre de raisons, ceux que je connais sont ...
-Queuing nouveaux tampons (à une source de diffusion en continu) si la source a déjà un bufferid affecté (car il se prépare à l'électricité statique si vous définissez un identifiant de tampon). Si c'est le cas, supprimez l'ID dans la propriété source.
-Changement du format du tampon en cours de lecture. Vous ne pouvez pas modifier les paramètres du tampon (fmt, samplerate) à l'exception des données de tampon elles-mêmes une fois qu'une source commence à jouer, même si elle se trouve dans une autre file d'attente.

Il semble que vous puissiez modifier l'un de ces paramètres dans un autre thread.

Une autre chose qui peut provoquer des pops est de rejouer le son. Appeler à nouveau la lecture arrête juste la source froide, puis rembobine le tampon actuel et commence à jouer depuis le début. Jouer un son de pistolet comme ça ne sonne pas comme vous le voulez (couches je suppose). 2 options, mélanger le son du pistolet restant dans le tampon puis le relire, mais cela pourrait ne pas fonctionner. Une autre preuve infaillible est juste d'utiliser plusieurs sources et de faire pivoter ceux qui sont appelés sur chaque feu de pistolet.

bonne chance pour votre projet.