I am creating an app that requires a sound or sounds to potentially be played every ~25ms. (300beats per minute with potentially 8 "plays" per beat)
At first I used SoundPool to accomplish this. I have 3 threads. One is updating the SurfaceView animation, one is updating the time using System.nanoTime(), and the other is playing the sounds (mp3s) using Soundpool.
This works, but seems to be using a lot of processor power as anytime a background process runs such as the WiFi rescanning, or GC, it starts skipping beats here and there, which is unacceptable.
I am looking for an alternative solution. I've looked at mixing and also the JET engine.
The JET engine doesn't seem like a solution as it only uses MIDIs. My app requires high-quality sounds (recordings from actual instruments). (correct me if I'm wrong on midi not being high quality)
Mixing seems very complicated with Android as it seems first you must get the raw sound (takes up a lot of memory) and also create "silence" in between sounds. I am not sure if this is the most elegant solution as my app will have variable speed (bpm) controlled by the user.
If anyone is experienced in this area, I would GREATLY appreciate any advice.
Thank you
Related
I am using SoundPool in order to play some sounds using timers in my applications. Does anyone know if there is an in-built queue where it will queue files and play them only when the previous files are finished?
Do I have to write my own implementation of a SoundPool queue?
I have had a similar issues in a couple of apps that relied heavily on SoundPool. There is no "in-built queue" or detection of when a sound has finished. Also annoyingly you can't get the play length of loaded sounds from SoundPool either. In your searches I'm sure you've come across many people complaining about this.
For my purposes I got around this by first briefly loading each sound into MediaPlayer to get and store it's play length. Then used these lengths to signify when playback will have stopped.
Unfortunately the audio side of things is a well recognised weak point in Android. The general advice is if you want to get accurate and have good control, then you need to turn to the NDK rather than using SoundPool or MediaPlayer, sorry.
My application takes a long time to prepare and buffer an audio stream. I have read this question Why does it take so long for Android's MediaPlayer to prepare some live streams for playback?, however it just says people have experienced this issue, it does not state how to improve the problem.
I am experiencing this in all versions of Android, tested from 2.2 - 4.1.2.
The streams are in a suitable bit-rate for mobile and 3G connection. The same stream takes less than a second to start buffering in the equivalent iOS app.
Is there a way to specify the amount of time that should be buffered? I know that the Tune In radio application offers this feature ( https://play.google.com/store/apps/details?id=tunein.player ).
Thanks.
Edit: I've tested again and found that it only happens on devices running Gingerbread and above (>=2.3). I know that Android changed the underlying framework from OpenCore to StageFright. So how can I optimise the media framework? It just seems wrong that the old HTC Wildfire can prepare, stream and play, literally 10x faster than the brand new HTC One X and Nexus 7.
I have struggled with this question for months. Finally i found the solution.
The real problem is in the implementation of the MediaPlayer class. Particularly with the way MediaPlayer buffers the data. This is why the solution is to create your own buffering, save it to a temp file and feed that to MediaPlayer.
This tutorial and source code explain exactly how. http://androidstreamingtut.blogspot.nl/2012/08/custom-progressive-audio-streaming-with.html
By adapting this code, it is easy to create a much better streaming player.
Google Developers really screwed up here.
EDIT : This answer is rather old. Nowdays i would recommend not using MediaPlayer and use ExoPlayer instead. It is extendable, stable and can play many different types of media. You can find it here: https://github.com/google/ExoPlayer/
There really isn't much you can do since the Android MediaPlayer class doesn't provide access to lower level settings such as buffer size. The only alternative would be to make your own player using AudioTrack and a library like FFmpeg to do the decoding.
The one thing I'd recommend is to play around with encoding. For instance, for MP4s, ensure that the MOOV Atom is located at the beginning of the file (there are enough questions on S/O regarding how to do this with ffmpeg, etc). With MP3s, you can look at different codecs or bitrates for instance.
You can, for instance, try a number of audio files you find online, and if you see one that doesn't take a long time to buffer, try to encode your files in the same way.
I'm working on a musical application that relies entirely on MIDI. I want this app to be around for quite awhile, into the next many OS editions, etc. (given normal upkeep and updates, etc.)
But since Microsoft, Java/Google/Android and others are showing signs of dropping MIDI support entirely from their APIs (at least the way I see it) maybe there is a movement to kill MIDI off...?
Anyway, I'm looking for a viable alternative to MIDI with its easy real-time interactivity. I hope to stay with MIDI but if the writing is on the wall I'd rather know now than wait. If MIDI weren't available, what would you do?
But since Microsoft, Java/Google/Android and others are showing signs of dropping MIDI support entirely from their APIs (at least the way I see it) maybe there is a movement to kill MIDI off...?
Where did you get this idea? MIDI isn't going anywhere, as it's so simple and universal. If you build an app using MIDI, it's definitely not in danger of becoming obsolete for that reason.
After downloading and using Xuggler, my initial impressions are very good; it supports a whole host of codecs, it was relatively hassle free to get going and the getting started tutorial videos explained all the necessary concepts very clearly.
However, after playing around with it for a couple of days I'm really tearing my hair out over getting all the audio and video to sync up nicely. It's fine when playing normally but when adding pausing, seeking and accounting for occasional 6 second pauses while my external hard drive spins up it becomes an absolute nightmare.
I've partly implemented something already but it's nowhere near perfect - you can seek around a few times but after a while it still drifts off.
I can't help thinking this is a common use case of Xuggler and someone must have done this sort of thing already much better than I have. But alas, I can't find any examples beyond the ones on the website. Is there a higher level API around that manages all the audio / video sync issues and just provides some higher level controls (play, pause, stop etc.)? I've no problem going down the route of doing it myself if there's nothing out there already, but I've never been a fan of reinventing the wheel (especially if my new wheel is in all likelihood worse than the old one!)
This is really a two part answer - the first being yes, there is a higher level "player" framework here. It's in early stages but much better than anything I would have cobbled together quickly, and I'm sure the guy running it would be open to any improvements in the code.
Secondly, I didn't really go with the above at all because I looked to VLCJ instead which uses libVLC which in turn has all the synchronisation stuff built in nicely. To get multiple players embedded in the application reliably you need to use out of process players (see here for how I went about doing it) but once that framework is in place it works reliably, fast and overall very well.
I read this code to play video files using xuggler as a library.When i run this code , the video without sound plays.Why is that ?
If not what should i do to play audio with video.?
Quite simply, it's because that code doesn't play any audio. It was never written to do so!
If you want to play audio and video, check out the example here:
http://xuggle.googlecode.com/svn/trunk/java/xuggle-xuggler/src/com/xuggle/xuggler/demos/DecodeAndPlayAudioAndVideo.java
The question to me suggests that you've just grabbed the source without looking at the tutorials - I'd strongly suggest doing so so you can understand the code behind what's going on rather than just throwing it in there and expecting it to work - especially if you're planning on using Xuggler in any great depth!
As a further note, if all you want to do is play videos I probably wouldn't advise using Xuggler because it's just not really designed for that sort of thing. Sure it will play them, but you have to manage all the sync issues yourself (which the above example doesn't do a great job of), it will only use your CPU and therefore really eat into its consumption especially if you're doing things like HD video, and the sheer amount of background code is just overkill (getting the streams, finding the stream IDs, extracting each packet, determining the type of the packet, dealing with it appropriately, managing errors, etc. etc.) It's a great piece of software, but if you're only using it to play stuff then it'll probably give you far more trouble than its worth.
Instead I'd advocate having a play with VLCJ - it's a bit complicated to get set up to work reliably (out of process players are required for rock solid stability) but when you've got that far it plays near any file type under the sun and manages all the issues above for you much, much better than you'll ever cope with by hand!
My guess is that you have a missing audio codec. I've had this same issue but vice versa; the sound played but the video didn't.