AudioTrack redémarre même après l'arrêt

J'ai créé une application simple qui génère un signal carré de fréquence donnée et en joue à l'aide de AudioTrack en mode FLUX (STREAM_MUSIC). Tout semble fonctionner correctement et le son joue bien, cependant lorsque le flux est fini, je reçois des messages dans le journal:

W/AudioTrack( 7579): obtainBuffer() piste 0x14c228 désactivé, le redémarrage de ...

Même après l'appel de la fonction stop (), je reçois toujours ces.
Je crois que j'ai bien mis les AudioTrack taille de la mémoire tampon, basée sur la taille minimale requise par AudioTrack (dans mon cas 6x1024). Je le nourrir avec de petits tampons de 1024 shorts.

Est-il normal que je reçois ces et dois-je le laisser comme ça?

source d'informationauteur Chris Koston

  1. 15

    Ok, je pense que le problème est résolu. L'erreur est générée lorsque la mémoire tampon n'est pas complètement rempli avec les données sur le temps (problème de mémoire tampon) . Je n'ai aucune idée de ce que le délai d'attente est, mais si vous rencontrez ce assurez-vous que:

    1. Vous n'appelez pas la méthode de la pièce jusqu'à ce que vous avez des données dans la mémoire tampon.

    2. Vous pouvez générer les données assez rapidement pour battre le délai d'attente.

    3. Après vous avez terminé d'alimentation de la mémoire tampon de données, avant d'appeler la méthode stop (), assurez-vous que la "dernière" de la mémoire tampon a été complètement remplie avec les données avant expiration.

    J'ai traité avec la dernière question, toujours en attente d'un peu (jusqu'au délai d'attente), puis l'envoi 1 tampon plein de zéros et de finalement l'appel de la fonction stop ().

    Gardez à l'esprit que vous devez toujours envoyer le tampon en petits morceaux, même si vous avez le gros morceau prêt. Il dérange encore un peu de moi que je ne suis pas sûr à 100% si c'est la bonne voie, mais les erreurs sont partis, donc je suppose que je peux vivre avec ça 🙂

  2. 5

    J'ai trouvé que même lorsque la mémoire tampon est techniquement assez long, et rempli avec des octets, si elles ne sont pas correctement formaté (audio shorts converti en un tableau d'octets), il sera toujours vous jeter cette erreur.

  3. 4

    Je recevais cet avertissement quand j'ai instancié Audiotrack, appelé audioTrack.play() et il y a un léger décalage entre le play() appel et la audioTrack.write(). Si j'ai appelé play() juste avant write() l'avertissement disparu.

  4. 0

    J'ai résolu de cette

            if (mAudioTrack.getPlayState()!=AudioTrack.PLAYSTATE_PLAYING)
            mAudioTrack.play();
        mAudioTrack.write(b, 0, sz * 2);
        mAudioTrack.stop();
        mAudioTrack.flush();