I'm using react-native-sound to playback looped audio files (exactly mp3 format). The problem is that there is a gap between the loops.
Here is my code example:
loadSound = (s) => {
let sound = new Sound(s, Sound.MAIN_BUNDLE, (error) => {
if (error) {
console.log('failed to load the sound', error);
return;
} else {
sound.setNumberOfLoops(-1);
}
});
return sound;
}
let sound = loadSound('campfire.mp3')
sound.play();
Is there any workaround how to make the loops to sound smooth?
Actually, this issue is open on github, but there is no solution yet...
There are gaps between loops because of the bug in Android MediaPlayer (which is used under the hood).
To fix the problem I've created the react-native-audio-exoplayer module, which has pretty same functionality as the react-native-sound, but it is based on the Android ExoPlayer. The API is a bit different but more robust and modern (have a look at the docs).
Later if I have time I'll do a pull request to introduce ExoPlayer in the react-native-sound.
But for now feel free to use react-native-audio-exoplayer as a good workaround (for now it's implemented only for Android).
Using the below version of the react-native-sounds fixed the gap issue.
https://github.com/Menardi/react-native-sound-gapless.git
From the README of the git repo:
Simply setting a track to loop on Android does not make it gapless,
instead leaving a short silence before restarting the track. However,
Android does actually support gapless playback between different
tracks. So, this fork essentially loads the same track twice, and gets
Android to handle the gapless playback for us. The downside is that
you will use more memory than before, because the track is loaded
twice. For most cases, this shouldn't matter, but you can profile your
app in Android Studio if you are concerned.
I have same issue with looping the sound. What I did to make it work is to call the same play sound function once sound play completed. I hope this will helps you.
function playBackground(){
bgSound = new Sound(bgMusic, (error, sound) => {
if (error) {
alert('error' + error.message);
return;
}
bgSound.play((success) => {
if(success)
{
// console.log("Play completed");
playBackground();
}
bgSound.release();
});
});
}
Related
I am using the Spotify android SDK, and I am trying to get a single song to play, and I would like to potentially play a song after the current one is completed. The issue is that after the song completes Spotify plays a random song afterwards. Is it possible to play the song and not have anything else automatically play after it?
I am simply calling the app remotes player API play function,
mSpotifyAppRemote?.getPlayerApi()?.play(uri)
#Mikee you are doing nothing wrong, Spotify messes around with track replay if you are only using the Free version, if you use Premium it will work correctly. Funny enough if you try playing by an alblum or artist that works with the Free version.
I'm not an expert but from their documentation it looks like you could watch the PlayerState. I'm also not sure when a PlayerState event would trigger but if it's coming back relatively often you could check the track value and see if it's gone to null, or another value and work using that.
Here's a Java example from their website:
// Subscribe to PlayerState
mSpotifyAppRemote.getPlayerApi()
.subscribeToPlayerState()
.setEventCallback(new Subscription.EventCallback<PlayerState>() {
public void onEvent(PlayerState playerState) {
// See what values are in playerState, might be able to determine
// if it's now randomly playing?
final Track track = playerState.track;
if (track != null) {
Log.d("MainActivity", track.name + " by " + track.artist.name);
// If the track is now different, your song has finished, stop it?
}
}
});
I've put a few extra comments in the code above that might yield some results!
Im building a react-native application.
Im trying to meter the current sound level (in decibel).
Libraries in use: react-native-audio and react-native-sound.
There is anybody familiar with this feature?
Thank you.
With the react-native-audio library, you can get the count for the only iOS.
For the currentMetering in Android, you need to customize in a native module. I have updated it add the following things in your package.json file instead of your code. You will get the currentMetering count for the Android as well as iOS.
"react-native-audio": "git+https://github.com/Harsh2402/react-native-audio.git",
You can use react-native-audio currentMetering value - in order to get the sound level in real-time.
First, you will have to initialise your recorder (which i will assume youve done). I use prepareRecordingAtPath in a similar way to below
AudioRecorder.prepareRecordingAtPath(audioPath, {
SampleRate: 22050,
Channels: 1,
AudioQuality: "Low",
AudioEncoding: "aac",
MeteringEnabled: true
});
then once you've called AudioRecorder.startRecording(); (Note you have access to .pause() and .stop() methods also
Now for handling the audio level, you are going to have to retrieve the data that is returned by the onProgress method. From what i remember, there should be some currentMetering value that you can access. Note that defining this behaviour will trigger the action every time a different decibel reading is retrieved. Like so
AudioRecorder.onProgress = data => {
let decibels = Math.floor(data.currentMetering);
//DO STUFF
};
Hope this helps,
We have created an app and for some reason any sound played through Howler that is set to loop has a 30 second or so delay before it actually begins when played on an Android device. Its as if the entire sounds needs to be loaded prior to playing. The sound itself is stored locally on the device and we are using .ogg's. Also this hasn't been an issue before and its only since we updated crosswalk to version 23+ (2.3.0)
Has anybody else come across this or potentially have a fix for this?
Ok so I have found out the issue was to do with Howler and not Crosswalk. Essentially when setting up a new Howl we need to pass the parameter html5:true.
This worked for me:
let gasLooper;
let gasSound = new Howl({
preload:true
, src: require('./assets/audio/Gas-loop.mp3')
, autoplay: true
, volume: 0.5
, onplay: ()=>{
gasLooper = setTimeout(()=>{
gasSound.play();
},450);
}
, onstop: ()=>{
clearTimeout(gasLooper);
}
});
I am developing a karaoke app which consist of animation and playback song. The most important thing here is very precise synchronization between both.
I implemented it few months ago and on iOS 9/10 everything was working great. We had a problem with Android app (ExoPlayer) because there were too big delay between playback and animation. Finally we found out that the problem was caused by wrong song format (mp3) - which was explained here: https://github.com/google/ExoPlayer/issues/3233. We fixed it by packing song into mp4 format (on iOS there is still mp3 used).
I use AVPlayer with HLS
self.player = AVPlayer(url: url)
//
var currentTime_: Double {
if let player = self.player {
return player.currentTime().seconds
}
return 0
}
Everything was ok until iOS 11 release. On iOS 11 there is the same desynchronization (player.currentTime is not accurate) that was on Android.
What's interesting is that even app that was build on iOS 10 SDK and is available on AppStore doesn't work properly on iOS 11 - but it still works great on iOS 10.
Nothing on server side was changed. So Apple had to change something in decoding/buffering. Right now we are working on changing audio format/decoding but still I am curious - why that has happened? Anyone encountered something similar?
Regards
You need use this option when create AVURLAsset
let asset = AVURLAsset(url: url, options: [AVURLAssetPreferPreciseDurationAndTimingKey: true])
If you not use this option, AVPlayer measures mp3 audio duration by file length, so it has small error to get duration.
As woosiki pointed it out, you need to use the AVURLAsset. Just keep in mind that loading of large files will take longer due to the pre-calculation of the precise duration. You may want to put a loader indicator.
func prepareAudioFile(with track: Track) {
guard let url = URL(string: track.streamURL) else {
return
}
let asset = AVURLAsset(url: url,
options: [AVURLAssetPreferPreciseDurationAndTimingKey: true])
let playerItem = AVPlayerItem(asset: asset)
player = AVPlayer(playerItem: playerItem)
observePlayerProgress()
}
private func observePlayerProgress() {
let interval = CMTimeMake(value: 1, timescale: 5)
player.addPeriodicTimeObserver(forInterval: interval, queue: .main) { [weak self] time in
if let track = self?.player.currentItem, track.status == .readyToPlay {
// Once the loading is finished this callback will return
// Here you can calculate and set duration and elapsed time (track.duration, time.seconds)
}
}
}
I am using cordova 6.4.0 with cordova-plugin-media for streaming radio-stations in an Android Application. Unfortunately there is a case, where the application is not responding properly anymore.
Let's say the user wants to stream a radiostation, but while the stream is loading, he wants to abort it (for example because the stream is down, or taking very long to load).
In this case I am not able to cancel the process!
media = new Media("http://direct.franceinfo.fr/live/franceinfo-midfi.mp3?ID=f9fbk29m84", mediaPlayerSuccess, mediaPlayerFail, mediaPlayerStatus);
media.play();
Now I want to cancel the process of buffering the stream, but I'm not able to. The functions:
media.pause();
media.stop();
are throwing error messages in the ADB-log and are calling the mediaPlayer-onError callback.
D/AudioPlayer( 3362): AudioPlayer Error: pausePlaying() called during invalid state: 1
...
D/AudioPlayer( 3362): AudioPlayer Error: stopPlaying() called during invalid state: 1
The media.release() command stops the loading of the stream! However just releasing the stream without stopping it, causes other, rather big problems:
Most of the times the system reacts just very slow and hangs a few seconds, if you call media.release() on a media-object. But if you do this often, the system completly freezes. Meaning it does not accetp remote-control commands anymore.
The Adb-log is still working, but does not show any errors in this case. Only the POWER-Button is still working (it locks and unlocks the screen). The only way to recover from this screwed-up state, is to reboot the device.
How am I supposed to cancel a Media-stream if it is not playing, yet? Is this a bug in the plugin?
Attached is the code-snippet, that I use to handle the media-streaming-logic. Like described above... it basically works, but it slows down or even freezes device, if you call it multiple times.
function radioControl(action, media_src){
//media_src is a webradio-streamurl.
if(action == 'play') {
// Initial Play
if(media === null){
mediaCreateObject(media_src);
}
// If we get PLAY but on antoher station
else if(media.src != media_src){
mediaReleaseRessources();
mediaCreateObject(media_src);
}
//interrupt_timer = false;
if(media === null){
mediaCreateObject(media_src);
}
media.play();
}
else if (action === 'pause') {
//If we get "pause", but it didn't even start yet
if(media._duration == -1){
mediaReleaseRessources();
}
else{
media.pause();
}
}
}
function mediaCreateObject(media_src){
media = new Media(media_src, mediaPlayerSuccess, mediaPlayerFail, mediaPlayerStatus);
}
function mediaReleaseRessources(){
media.release();
}
I found out, that this is not a cordova issue, but an 8 year-old (!) android-bug, that was never fixed. See here:
https://code.google.com/p/android/issues/detail?id=959
MediaPlayer "crash" (deadlocks the calling thread) when resetting or releasing an unused MediaPlayer
Basically the problem is: If you try to "release" a media-object that is not playing (yet), it will deadlock the calling thread, which causes the freezing that I have mentioned in the question. Unfortunately they never fixed this bug, but just marked it as "obsolete". In Android 5.1.1. the bug apparently is still there. Maybe they fixed it in later versions.
I have made a rather ugly workaround for this problem, but it is working. Basically what I did is:
We save every media-object in a javaScript-object. If the user stops it, while it plays, we can just stop and delete the object. But if it is not playing, we leave this media-object in this javaScript-object media_objects = {};
Also we save the currently active_media stream in a variable.
If cordova calls the mediaPlayerStatusChange-callback we loop through the media_objects and check if the status of one of the "pending"-objects has now changed to "running". - Cordova justs calls the media-status-change-callback without any indictation what media-object exactly just changed the state. That is unfortunate, so we have to check if one of the pending-"obsolete" objects now started playing. If so, we can stop and release it. (If the object is actually playing, stop and release works like intended - only if it's not playing, it causes the crash)
function mediaPlayerStatusChange(status){
mediaReleaseRessources();
// handle status change....
// ......
}
function mediaReleaseRessources(){
for(var key in media_objects) {
// We can only stop-and release an object, if it is playing
// If an object started playing, the "_duration"-value is != -1
if(key !== active_media && media_objects[key]._duration != -1) {
media_objects[key].stop();
media_objects[key].release();
delete media_objects[key];
}
}
}
This solution works for me, however I am still interested in a better and cleaner way to handle multiple media-streams in cordova.