MediaPlayer bégaie au début de la lecture de mp3

J'ai eu un problème de lecture d'un fichier mp3 stockés dans une ressource brute: lorsque le fichier de la première commence à jouer, il génère peut-être un quart de seconde de son, puis redémarre. (Je sais que c'est fondamentalement un double du problème décrit ici, mais la solution proposée n'a pas fonctionné pour moi.) J'ai essayé plusieurs choses et ont fait des progrès sur le problème, mais il n'est pas totalement fixe.

Voici comment je me suis mise à lire un fichier:

mPlayer.reset();
try {
    AssetFileDescriptor afd = getResources().openRawResourceFd(mAudioId);
    if (afd == null) {
        Toast.makeText(mOwner, "Could not load sound.",
                Toast.LENGTH_LONG).show();
        return;
    }
    mPlayer.setDataSource(afd.getFileDescriptor(),
            afd.getStartOffset(), afd.getLength());
    afd.close();
    mPlayer.prepare();
} catch (Exception e) {
    Log.d(LOG_TAG, "Could not load sound.", e);
    Toast.makeText(mOwner, "Could not load sound.", Toast.LENGTH_LONG)
            .show();
}

Si je quitte l'activité (qui appelle mPlayer.release()) et de revenir à elle (la création d'un nouveau lecteur multimédia), le bégaiement est généralement (mais pas toujours) disparu—fourni je charge le même fichier audio. J'ai essayé un couple de choses que ne fait pas de différence:

Charger le fichier audio comme un atout plutôt que comme une ressource.
Créer le lecteur multimédia à l'aide de MediaPlayer.create(getContext(), mAudioId) et ignorer les appels à setDataSource(...) et prepare().

Puis j'ai remarqué que LogCat montre toujours cette ligne à environ le temps que la lecture commence:

DEBUG/AudioSink(37): bufferCount (4) is too small and increased to 12

Il m'a demande si le bégaiement est en raison de l'apparente rebuffering. Cela m'a conduit à essayer quelque chose d'autre:

Après l'appel de prepare(), appel mPlayer.start() et appeler immédiatement mPlayer.pause().

À mon agréable surprise, ça a eu un grand effet. Une grande partie de la bégaiement est parti, plus aucun son (que je peux entendre) est effectivement joué à ce point dans le processus.

Cependant, il bégaie toujours de temps en temps quand je l'appelle mPlayer.start() pour de vrai. De Plus, cela semble être un énorme bidouille. Est-il possible de tuer ce problème complètement et proprement?

MODIFIER Plus d'infos; vous ne savez pas si liés. Si je l'appelle pause() pendant la lecture, demander à une position antérieure, et d'appeler start() de nouveau, j'entends un peu court (~1/4 s) de sons supplémentaires, d'où il a été interrompu avant qu'il ne commence à jouer à la nouvelle position. Cela semble plus de mise en mémoire tampon des problèmes.

Aussi, le bégaiement (en pause et en mémoire tampon) les problèmes apparaissent sur les émulateurs de 1,6 à 3.0.

Pour ceux avec de bons souvenirs, appelant start() et pause(), comme cela pourrait vous rappeler de la tour que nous avons l'habitude d'avoir à faire à force de pré-chargement d'un AudioClip dans une page web applet. 🙂
C'est peut-être à voir avec l'encodage du fichier audio, ou, éventuellement, la longueur de celui-ci. Avez-vous essayé d'utiliser votre code avec un autre fichier audio?
ce qui se passe avec quatre fichiers, allant de 56 secondes à peine plus de 4 minutes. Chacun est un seul flux de données audio à l'aide de MPEG Audio Layer 1/2/3 (mpga), dans le stéréo de 44100 hz fréquence d'échantillonnage de 128 ko/s débit binaire. Ils ont été générés avec GarageBand 5.1. J'ai essayé de ré-enregistrer les fichiers avec Audacity 1.3. Pas de changement. La lecture de fichiers amende dans les médias de joueurs sur mon ordinateur.
Faire des fichiers MP3 à jouer dans la valeur par défaut d'Android media player ou autre lecteur média Android apps. Si oui, alors il semble que vous avez exclu l'encodage/débit binaire du fichier. Si non, alors essayer quelques-uns des Mp3 que viendra avec Android.
La lecture de fichiers très bien quand je les ai mis sur la carte sd et de les jouer avec l'application Musique.
Pourriez-vous m'aider à ce Question

InformationsquelleAutor Ted Hopp | 2011-03-17

67

Autant que je sache, les tampons qui MediaPlayer crée en interne sont pour le stockage de décompressé échantillons, pas pour le stockage de prefetched données compressées. Je soupçonne votre bégaiement vient de I/O lenteur qu'il se charge plus MP3 de données pour la décompression.

J'ai récemment eu à résoudre un problème similaire avec la lecture vidéo. Grâce à MediaPlayer étant pas en mesure de jouer un arbitraire InputStream (l'API est étrangement boiteux) la solution je suis venu avec était d'écrire un petit cours de processus de serveur pour servir des fichiers locaux (sur la carte SD) via HTTP. MediaPlayer charge ensuite via une URI de la forme http://127.0.0.1:8888/videofilename.

EDIT:

Ci-dessous est la StreamProxy classe-je utiliser pour nourrir le contenu dans un lecteur multimédia instance. L'utilisation de base est que vous instanciez, start (), et votre lecteur multimédia aller avec quelque chose comme MediaPlayer.setDataSource("http://127.0.0.1:8888/localfilepath");

Je note que c'est plutôt expérimental et n'est probablement pas entièrement exempt de bogues. Il a été écrit pour résoudre un problème similaire à la vôtre, à savoir que MediaPlayer ne peut pas lire un fichier qui est également en cours de téléchargement. De la diffusion d'un fichier localement dans cette façon fonctionne autour de cette restriction (c'est à dire, j'ai un fil de télécharger le fichier alors que la StreamProxy insère dans mediaplayer).
```
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.OutputStream;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.SocketException;
import java.net.SocketTimeoutException;
import java.net.UnknownHostException;
import android.os.AsyncTask;
import android.os.Looper;
import android.util.Log;
public class StreamProxy implements Runnable {
private static final int SERVER_PORT=8888;
private Thread thread;
private boolean isRunning;
private ServerSocket socket;
private int port;
public StreamProxy() {
//Create listening socket
try {
socket = new ServerSocket(SERVER_PORT, 0, InetAddress.getByAddress(new byte[] {127,0,0,1}));
socket.setSoTimeout(5000);
port = socket.getLocalPort();
} catch (UnknownHostException e) { //impossible
} catch (IOException e) {
Log.e(TAG, "IOException initializing server", e);
}
}
public void start() {
thread = new Thread(this);
thread.start();
}
public void stop() {
isRunning = false;
thread.interrupt();
try {
thread.join(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
@Override
public void run() {
Looper.prepare();
isRunning = true;
while (isRunning) {
try {
Socket client = socket.accept();
if (client == null) {
continue;
}
Log.d(TAG, "client connected");
StreamToMediaPlayerTask task = new StreamToMediaPlayerTask(client);
if (task.processRequest()) {
task.execute();
}
} catch (SocketTimeoutException e) {
//Do nothing
} catch (IOException e) {
Log.e(TAG, "Error connecting to client", e);
}
}
Log.d(TAG, "Proxy interrupted. Shutting down.");
}
private class StreamToMediaPlayerTask extends AsyncTask<String, Void, Integer> {
String localPath;
Socket client;
int cbSkip;
public StreamToMediaPlayerTask(Socket client) {
this.client = client;
}
public boolean processRequest() {
//Read HTTP headers
String headers = "";
try {
headers = Utils.readTextStreamAvailable(client.getInputStream());
} catch (IOException e) {
Log.e(TAG, "Error reading HTTP request header from stream:", e);
return false;
}
//Get the important bits from the headers
String[] headerLines = headers.split("\n");
String urlLine = headerLines[0];
if (!urlLine.startsWith("GET ")) {
Log.e(TAG, "Only GET is supported");
return false;               
}
urlLine = urlLine.substring(4);
int charPos = urlLine.indexOf(' ');
if (charPos != -1) {
urlLine = urlLine.substring(1, charPos);
}
localPath = urlLine;
//See if there's a "Range:" header
for (int i=0 ; i<headerLines.length ; i++) {
String headerLine = headerLines[i];
if (headerLine.startsWith("Range: bytes=")) {
headerLine = headerLine.substring(13);
charPos = headerLine.indexOf('-');
if (charPos>0) {
headerLine = headerLine.substring(0,charPos);
}
cbSkip = Integer.parseInt(headerLine);
}
}
return true;
}
@Override
protected Integer doInBackground(String... params) {
long fileSize = GET CONTENT LENGTH HERE;
//Create HTTP header
String headers = "HTTP/1.0 200 OK\r\n";
headers += "Content-Type: " + MIME TYPE HERE + "\r\n";
headers += "Content-Length: " + fileSize  + "\r\n";
headers += "Connection: close\r\n";
headers += "\r\n";
//Begin with HTTP header
int fc = 0;
long cbToSend = fileSize - cbSkip;
OutputStream output = null;
byte[] buff = new byte[64 * 1024];
try {
output = new BufferedOutputStream(client.getOutputStream(), 32*1024);                           
output.write(headers.getBytes());
//Loop as long as there's stuff to send
while (isRunning && cbToSend>0 && !client.isClosed()) {
//See if there's more to send
File file = new File(localPath);
fc++;
int cbSentThisBatch = 0;
if (file.exists()) {
FileInputStream input = new FileInputStream(file);
input.skip(cbSkip);
int cbToSendThisBatch = input.available();
while (cbToSendThisBatch > 0) {
int cbToRead = Math.min(cbToSendThisBatch, buff.length);
int cbRead = input.read(buff, 0, cbToRead);
if (cbRead == -1) {
break;
}
cbToSendThisBatch -= cbRead;
cbToSend -= cbRead;
output.write(buff, 0, cbRead);
output.flush();
cbSkip += cbRead;
cbSentThisBatch += cbRead;
}
input.close();
}
//If we did nothing this batch, block for a second
if (cbSentThisBatch == 0) {
Log.d(TAG, "Blocking until more data appears");
Thread.sleep(1000);
}
}
}
catch (SocketException socketException) {
Log.e(TAG, "SocketException() thrown, proxy client has probably closed. This can exit harmlessly");
}
catch (Exception e) {
Log.e(TAG, "Exception thrown from streaming task:");
Log.e(TAG, e.getClass().getName() + " : " + e.getLocalizedMessage());
e.printStackTrace();                
}
//Cleanup
try {
if (output != null) {
output.close();
}
client.close();
}
catch (IOException e) {
Log.e(TAG, "IOException while cleaning up streaming task:");                
Log.e(TAG, e.getClass().getName() + " : " + e.getLocalizedMessage());
e.printStackTrace();                
}
return 1;
}
}
}
```
- Intéressant. Suggérez-vous que je décoder les fichiers mp3 en quelque chose de non compressé (comme PCM/WAVE) et les aliments que pour MediaPlayer?
- Pas du tout, je suggère que vous la précontrainte de certaines ou de toutes les données compressées dans la mémoire. Je pense que votre problème est que lorsque vous donnez simplement MediaPlayer un FileDescriptor, il n'a pas de tampon suffisamment de données pour alimenter le MP3 décompresseur... vous souffrez d'un problème de mémoire tampon, d'où le bégaiement.
- Ah. Cela expliquerait pourquoi l'astuce de l'appel de la méthode start (), puis une pause() dès le début aurait un effet. Je suis à la théorie de la que ce n'était pas pleinement efficace, car l'appel à la pause() est venu trop tôt, de sorte que le tampon n'ai pas la chance de se remplir. J'ai remplacé le départ/pause séquence avec un appel à seekTo(500) (et trafiqué onSeekComplete) et le bégaiement semble maintenant avoir disparu!
- Heureux que vous avez trouvé un moyen de sortir. Si plus tard vous trouvez que vous avez besoin de l'avancée de mise en mémoire tampon de la solution (c'est à dire le streaming HTTP le fichier dans le lecteur multimédia dans le cadre du processus) alors laissez-moi savoir et je vais vous envoyer le code.
- Je voudrais voir ton code. Nous ne pouvons pas en avoir besoin pour cette application, mais nous prévoyons d'autres applications qui vont utiliser MediaPlayer et il serait bon de disposer d'un outil comme ça sur la main.
- Bonne explication. Il serait préférable de l'accès aux données à l'aide d'un ContentProvider mais plutôt que les paramètres d'un serveur.
- Hopp - Qu'entendez-vous par ". J'ai remplacé le départ/pause séquence avec un appel à seekTo(500) (et trafiqué onSeekComplete) et le bégaiement semble maintenant avoir disparu!".. Pouvez-vous partager ce tordu de code s'il vous plaît, j'ai exactement le même problème et à la recherche d'une solution pour un looong moment !!
- Après le media player est prêt, j'ai mis un drapeau pour indiquer que je suis en train de faire la première rechercher et appeler seekTo(500). Dans onSeekComplete, je vérifie le drapeau et, si elle est définie, j'clair et appeler seekTo(0); sinon, j'appelle start(). Simple.
- Merci cela fait du sens, j'ai essayé ceci mais le fait d'être un noob, je pense que j'ai foiré la onSeekComplete mise en œuvre. Pouvez-vous s'il vous plaît partager ce morceau de code ? Mon code se lit comme suit: mp.reset(); mp.prepare(); mp.seekTo(500);mp.setOnSeekCompleteListener(nouveau OnSeekCompleteListener() { @Override public void onSeekComplete(MediaPlayer mp) { mp.start();} });mp.seekTo(0); mp.start();
- Essayez de régler votre OnSeekCompleteListener avant de commencer la recherche. Aussi, mon code est plus comme ceci: boolean initialSeek; /* member field */ mp.reset(); mp.prepare(); mp.setOnSeekCompleteListener(new OnSeekCompleteListener() { @Override public void onSeekComplete(MediaPlayer mp) { if (initialSeek) { initialSeek = false; mp.seek(0); } else { mp.start(); } } }); initialSeek = true; mp.seekTo(500);
- Pouvez-vous s'il vous plaît partager le "Utils" de la classe, je suis en train d'essayer votre solution, mais j'ai une erreur sur cette ligne: Utils.readTextStreamAvailable Pouvez vous s'il vous plaît jeter un oeil à cette question: stackoverflow.com/questions/8681550/...
- Faire la lecture et le téléchargement des processus en même temps? J'ai essayé, mais à partir du journal, il semble que la vidéo est réel à jouer après avoir téléchargé le fichier, bien que j'appelle méthode de lecture après avoir téléchargé de la 10percent.
- pouvez-vous m'envoyer le code d'exemple de comment vous servir en cours de téléchargement de fichiers vers le lecteur multimédia à l'aide de streamproxy?
- Ne peut pas le faire parce que je n'utilise pas cette hacky technique de plus. Ces jours-je éviter MediaPlayer complètement parce que c'est peluche avec des bugs. Je l'ai remplacé par un port de FFmpeg avec un puissant Java personnalisé wrapper qui, entre autres choses, vous permet de jouer arbitraire InputStreams.
- Pouvez-vous envoyer le guide-moi comment Tu avais utilisé FFmpeg dans android pour la diffusion et la lecture de contenu audio?
- C'est vraiment un processus complexe. Vous suggère de regarder à un projet open-source qui l'utilise, par exemple, bambuser.com/opensource
- Pourriez-vous m'aider à ce stackoverflow.com/questions/16264225/... ?
- Bonjour @ReubenScratton, avez-vous experiance avec streaming un audiofile à partir d'un téléphone android via RTP à certains autres appareils sur le même réseau? Je suis en train de le faire, mais je peux entendre que le silence: stackoverflow.com/questions/18257438/...
- Salut.. je suis en train de mettre en œuvre le streaming Http solution..vous pouvez poster votre code..Merci d'avance
- J'ai modifié ton code pour servir chiffré mp3, il prend en charge les demandes de plage et devrait fonctionner dans ce cas aussi, gist.github.com/frostymarvelous/26ac6cba11bf50e591a4
- Je sais, ça fait un bout de temps... mais, si u rappelez-vous, pouvez-vous expliquer pourquoi vous avez utilisé seekTo(500) ?... Quelle est la logique derrière ce / comment cela pourrait-il résoudre le problème? Merci à l'avance.
- L'idée était que la recherche serait forcer le système à lire dans le début de l'audio, de données, de sorte que le processus de mise en mémoire tampon auraient déjà commencé par le temps de la lecture a commencé. Il est basé sur la théorie (non vérifiées mais on soupçonne fortement) que le bégaiement est dû à des problèmes de mise en mémoire tampon.
- Merci pour la réponse.. Dans mon cas, je suis en attente jusqu'à ce qu'il est de 10% tampon avant de me lancer(). Cette approche est-elle bien dans la première place? Mais même alors, son bégaiement. Peut-être que le pour cent de la valeur de onBufferingUpdate() ne peut pas être digne de confiance (ou, attendez quelques échantillons avant de prendre une décision?)...serions reconnaissants si u peut donner une idée. Je reçois le problème, seulement de façon aléatoire (les fichiers mp3 à partir du serveur).
- Est-ce vraiment encore une question en 2015? J'ai pensé qu'ils avaient une demi-décent cadre de maintenant...
- (Et FWIW mon commentaire d'origine est toujours debout... charger le mp3 de données en mémoire vous-même plutôt que de laisser MediaPlayer faire (mal), et le problème s'en va)
- Sous ma théorie de ce qui va mal, de lire des fichier audio (par ex., 10%) ira à l'encontre de la stratégie parce que la première partie des données audio ont été poussés hors de l'tampons pour faire de la place pour plus tard de données. (Ruben - la situation est meilleure avec les améliorations de l'API de 19 et de nouveau dans les 23, mais il ya encore des questions. Vous pouvez trouver cette analyse informatif [mais sachez que c'est de brancher un produit].)
- Ted Hopp et Reuben Scratton: Merci pour votre temps et vos éclaircissements... maintenant, à compter de 10% fonctionne très bien pour moi (Il n'est pas en direct et en streaming). Va considérer le changement si je vois des problèmes lors de régressif test... Merci encore!
- la lecture à partir de 10% tamponné ne fonctionne plus... Ted Hopp Ruben Scratton, pourriez-vous nous donner un peu d'aide / suggestions? NOTE: je suis la lecture des fichiers mp3 à partir d'un serveur. Très frustrant... Googler ne pas faire beaucoup d'aide.
- Je garde de le dire: Ne pas laissez-MediaPlayer ne le streaming, c'est complètement inutile, et de commencer la lecture à x% ne changera pas ce fait. La seule façon de faire MediaPlayer jouer de manière fiable consiste à extraire les données vous-même, c'est à dire de télécharger certaines ou toutes les données vous-même à une zone de mémoire RAM et ensuite nourrir que de lecteur multimédia via HTTP.
InformationsquelleAutor Reuben Scratton
3

Serait à l'aide d' prepareAsync et de répondre à setOnPreparedListener vous conviennent le mieux? En fonction de votre activité flux de travail, lorsque le MediaPlayer est d'abord initialisé à définir les préparation de l'auditeur et ensuite appeler mPlayer.prepareAsync() plus tard, une fois que vous êtes en fait le chargement de la ressource, puis démarrez la lecture. J'utilise quelque chose de similaire, mais pour un réseau de diffusion de ressources:
```
MediaPlayer m_player;
private ProgressDialog m_progressDialog = null;
...
try {
if (m_player != null) {
m_player.reset();
} else {
m_player = new MediaPlayer();
}
m_progressDialog = ProgressDialog
.show(this,
getString(R.string.progress_dialog_please_wait),
getString(R.string.progress_dialog_buffering),
true);
m_player.setOnPreparedListener(this);
m_player.setAudioStreamType(AudioManager.STREAM_MUSIC);
m_player.setDataSource(someSource);
m_player.prepareAsync();
} catch (Exception ex) {
}
...
public void onPrepared(MediaPlayer mp) {
if (m_progressDialog != null && m_progressDialog.isShowing()) {
m_progressDialog.dismiss();
}
m_player.start();
}
```
Il y a évidemment plus d'une solution complète (gestion des erreurs, etc.) mais je pense que cela doit fonctionner comme un bon exemple pour démarrer à partir de ce que vous pouvez tirer le streaming de.
- Je vais essayer ce rapport et les effets. Je ne tiens pas beaucoup d'espoir pour elle, parce que le problème n'est pas dans le temps de la préparer; il semble être le traitement qui en est fait après start() est appelé. Mais alors, je serai le premier à admettre que je n'ai pas de comprendre pleinement comment MediaPlayer fonctionne en interne.
- J'ai essayé aujourd'hui de cette variation et il n'a eu aucun effet sur le problème.
- Pourriez-vous partager quelques détails sur le fichier en cours de lecture? Quel est le débit? Ce codeur a été utilisé pour construire le MP3 conteneur? Je réalise que c'est une solution, mais peut-être vous êtes simplement en attendre trop et que l'appareil a du mal à repousser les données, donc un débit inférieur pourrait résoudre votre problème. Aussi, est-ce dans l'émulateur? Le problème se produit sur les différents appareils?
- Quatre fichiers sont impliqués. Ils ont été créés par GarageBand 5.1 avec une fréquence d'échantillonnage de 44100 hz. Trois sont à un débit de 128kbs et sont à peu près une minute chacun. La quatrième, à environ 4 minutes, est à 86kbs. La lecture de fichiers en douceur après la période initiale de bégayer (en fait, plus comme un redémarrage), alors je me demande comment débit pourrait être la question.
- J'ai tenté de trouver la source de Android MP3 et ont été infructueuses. Certains encodeurs ne sont pas toujours de créer le conteneur dans la manière la plus efficace et peut-être la lecture de MP3 module pour Android est accrochée pour un moment. Peut-être vous pouvez essayer d'exporter les fichiers audio en tant que pure PCM et ensuite à l'aide d'un autre encodeur comme BOITEUX pour voir si cela fait une lecture différences. Vous pouvez également compléter les pistes audio avec une demi-seconde de silence, afin que le bégaiement n'est pas entendu. Je me rends compte ce sont des solutions de contournement, mais MediaPlayer semble immuable à ce point; le tampon ne peut pas être ajusté.
- suivant le commentaire de @Joseph, j'ai joué les fichiers dans le lecteur de musique. Ils jouent bien. J'avais déjà pensé à la demi-seconde de silence. Qui fonctionne dans nos tests, mais je me sens très mal à l'aise de ne pas savoir ce qui se passe vraiment mal; il peut réapparaître une fois que nous libérer de l'application et il se met à fonctionner sur une plus grande variété de matériel.
- Pourriez-vous m'aider à ce stackoverflow.com/questions/16264225/... ?
InformationsquelleAutor Matt Bishop

Vous devez vous connecter pour publier un commentaire.