I'm creating an app where I need to load OGG audio files into a SoundPool, but it must be compatible with Android 2.1 (which does NOT support onLoadingCompleteSetListener). Because of this, there's no way to tell if the sound file is loaded before playing it.
To bypass this, I put a Thread.sleep(1000); right after loading the audio file to give it some time to load. But now without the onLoadingCompleteSetListener method, my audio files are extremely static-y and unclear. It sounds horrible. But I'm not getting the "sample # not ready!" warning in LogCat so I think the Thread.sleep(1000); is doing its job.
But does Thread.sleep(1000); also stop the loading process? So actually I'm not giving it time to load and that's why it's static-y? I can't figure this out, I just need my audio to be clearer. Any suggestions could help.
Thanks!
Solved myself, used Audacity to normalize and compress the audio files after learning about it from the answer in another one of my questions: Audio Sound Too Low in Android App
Fixed all the static
Related
Let me refraise my question, I wrote it in a hurry.
Current situation:
I have set up a digital video recorder to record broadcasts provided via DVB-C. It is running on a raspberry 3B using TVHeadend and jetty/cling to provide UPnP and other possibilities to access media files. For watching recordings, I wrote an android player app using IJKPlayer, which runs on smartphones, FireTV and AndroidTV.
One hassle when playing media files which are currently beeing recorded is, that IJKPlayer doesn not support timeshifting. Means, when I start playing a currently recording file, I can only watch the length which is known by the player at that moment. Anything which is recorded afterwards can not be played. I need to exit the player activity and start it again. I have resolved that issue by "simulating" a completed recoding using a custom servlet implementation. Since the complete length of the recording is already known, I can use ffmpeg to accomplish this.
Future situation:
I plan to move away from IJKPlayer to ExoPlayer, because it supports hardware playback and is much faster when playing h.264 media. I can of course use the same solution like above, but as far as I have found out yet, ExoPlayer can support media files which are currently being recorded by using the Timeline class. However, I don't seem to find neither a usefull documentation nor any good example. Hence, I would appreciate any help with the timeline object.
Regards
Harry
Looks like my approach won't work. At least, I didn't find a solution. Problem is, that the server returns the stream size as it is during player-start-time. I didn't find a method to update the media duration for "regular" files.
However, I can solve the problem by changing the server side. Instead of accessing a regular file, I convert the file to m3u8 in realtime, using ffmpeg. I then throw the m3u8 URI onto the player and it updates the duration of the stream (while playing) without the need to create any additional code on the client side.
I have started a android.media.MediaPlayer file with:
mp1.start()
and then trying the looping with:
setLooping(true);
but this is ending up with a delay in playing the file again.
I am trying to run an mp3 file containing a rhythm with a set tempo. Is there any better way of looping it in such a manner that the tempo timing does not get disturbed and the rhythm plays seamlessly without any stutter/delay?
Should I use SoundPool instead?
Most of best practices for this particular case recommend using .ogg format. You can convert you file easily using VNC media player.
Wiki for .ogg file format - http://en.wikipedia.org/wiki/.ogg
Another solution is the SoundPool and the third one - is to use Audacity and cut the quiet/“blanksound” from you audio file.
If your audio is not long, then use SoundPool for low-latency media playback, instead of MediaPlayer. Also convert it to ogg, as others have already pointed it out.
Edit: if it is just a tempo, and not a continous sound, then maybe you can also measure the latency and seek your audio based on that, but I am not sure you will get better results this way.
Mediaplayer solutions:
If you insist on using MediaPlayer, then you can:
either crop the sound at the end of your audio files, so there's no sound gap between two playback loops
or create a custom solution yourself as the one described here.
Soundpool alternative:
Now, from my personal experience, if you want to loop files small in size and duration, not more than 1MB, then Soundpool is more convenient and it seems that not any relevant problems are reported in contrary to the MediaPlayer. There have been many complaints when trying to loop sounds using MediaPlayer, so generally Soundpool is usually preferred for looping.
Soundpool size limit:
If you are concerned about Sounpool's size limit, keep in mind that it has 1Mb buffer size limit per track. But this limit applies not to file size but to decompressed raw PCM data. SoundPool is going to decompress the loaded audio to PCM data so it is ready to play instantly without the latency of decoding. If the audio you are loading is compressed heavily, such as MP3, then that can get blown up quite a bit.
Improve performance:
Also, as suggested in another answer, files of type ".ogg" according to many sources appear to perform better than ".mp3" in general. So, you should try to convert your files for better performance, but I don't think you will see an improvement concerning looping.
To convert your files you can use an online tool such as this. If you convert your files remember to also make these changes:
Change your sound file's sampling rate to 16000 Hz
Change your audio channel to mono, instead of stereo.
Make sure your file after these processes is smaller than 1 mb in size.
Please try to do it this way.
audio = MediaPlayer.create(this, R.raw.pl);
audio.setLooping(true);
audio.start();
I'm playing mp3 file streamed from the network in my application, some mp3 files has weird behavior: mediaPlayer.getCurrentPosition() is larger than mediaPlayer.getDuration() at the end, for about 3 seconds.
The mp3 files are CBR encoded.
What might be the reason of this?
Finally solved the problem by converting the mp3 files, this is the command I'm using:
lame --mp3input -t -m s -b 128 --cbr input.mp3 output.mp3
There is a few reasons you can get this behavior.
First it appears that people had better results using mp3 files at exactly 44100Hz, because apparently the MediaPlayer class is assuming this value and scale the time accordingly, making strange values for files not using this sampling.
You also need to check the mode of your channels, and try using Joint Stereo or forced L/R Stereo. Joint should be the default, but your files might have been previously bad encoded, so it's worth trying. It's interesting to note that Forced L/R Stereo might loose quality for the same bitrate as Joint.
It would also be useful to check the output of soxi which is part of the sox package (you can also do it with ffmpeg), that will give you the number of channels, Sample rate, Bit Rate and Number of Channels.
Also you might want to check the raw content of the mp3 file if you did some treatment on them using any app for the presence of garbage xml content that might have been inserted during the export.
If you have the possibility to modify the mp3 files you're streaming, (which sounds like you do since you can tell the bitrate) these are what I would try first. If it's more like user-upload kind of stuff, maybe you should have a look to another solution instead, like ExoPlayer which has a few thousands stars and active development. It wraps the MediaPlayer api still, but worth a try.
You also have to consider that it might be a threading problem, where the player would stop playing, but the timer would actually keep going, giving you this result where it's superior to the actual duration of the song. 3 seconds seems a bit too much to explain it by that, but that's just a thought.
I am currently trying to make a Soundboard application for my Android.
Using Eclipse, I have successfully made buttons and coded them so that when pressed, they play .ogg sounds in the res/raw folder. All is okay.
Now, I have discovered that any files over about 6 seconds long aren't playing fully.
Is there any way to correct this problem? I would normally just trim the files, but some of them need to be a bit longer, but none are over 50 seconds.
Thanks alot!
What is happening is the mediaPlayer.start() instruction is being called before the file has finished fully loading. Assuming you are using mediaPlayer.create(this, resid) followed by .start() there are a few things that can help. The "right" way to do it is to put the .start() instruction inside of an onPreparedListener since .create calls .onPrepared the first time, but honestly when I put that in my soundboards I got tons of crash reports, so I reverted to just using .start after .create.
I found the problem usually occurs if the sound file is very high bitrate, or if the app is installed on a slow sdcard. I use mp3's, but usually cap the bitrate at 96k and put in the app description that if the clips aren't playing fully to move the app back to internal memory and the complaints seem to have stopped.
I am playing a setLooped enabled audio file in my app, but every time the audio file loops, there is a noticeable, though very brief, gap in the audio playback... is there any way to get around this?
I was just facing the same problem and I guess you have been using MP3 or OGG files or some other compressed format. The solution is to use WAV files instead. This may increase your apk size but lets you loop gapless.
I had the same problem and did try to switch from MP3 to WAV. Then looping worked gaplessly in emulator, but not in my phone. Using OGG files actually made it work in phone too. So using .ogg could be worth a shot too, but I don't actually underst