Which SIP library should we look at to solve our audio delay/latency issue for Android phones running OSes 4.0 and above?
Our experiments suggest the delay is a SIP library issue. If not a library issue, what else could it be?
We built a simple VOIP app for both Android and iPhone. You simply dial the caller id of another user, press call, and start talking to them. The iPhone version works great, and we used a commercial API for the SIP functionality. But the Android version doesn't work so well because of audio delay issues which seems to depend on which Android phone you have. We used the following Android SIP library.
Our Experiments and Findings
When we are making calls between one android phone to another android phone, there is too much delay in the audio. One person will say something, and it could take up to a full 1-2 seconds before the other person hears it. At the moment, this problem appears to be particular to Samsung devices, as opposed to other hardwares (although our tests have been limited). So for example, a Galaxy Note 1 calling a GS3 experiences more delay than a Galaxy Note 1 calling Nexus 7 tablet (Asus) and Galaxy Note 1 calling a Xiaomi MI-2 phone.
We're pretty sure we've eliminated our Asterisk server as the probable cause of delay, since iphone to iphone calls are great, and iphone to android calls are reasonable.
Here is a list of device speed tests, listed in ascending order of delay
iphone to iphone (fastest, no noticeable delay)
android (Samsung) to iphone (a little delay, but still acceptable)
android (samsung) to android (xiaomi MI-2) (a little delay, but still acceptable)
android (samsung) to android (asus) (too much delay, unacceptable)
android (samsung) to android (samsung) (really slow, unacceptable)
Right now, my team is is leaning towards the idea that the Android SIP library we are using is not good enough. We are interested in using another SIP library to do the call.
We have noticed that other Android SIP phones like CSipSimple also experiences this problem.
Does anyone have ideas on how we can solve our audio delay/latency issues?
Additional Notes
We noticed there wasn't any audio delay when using Skype on Galaxy Note 1 to Skype on Galaxy S3. So that's why we were thinking there's probably a solution to this problem via our choice of SIP library, or codec or something...
We know we're using the G.711 Codec, incase that makes any difference.
We fixed the voip latency issue by using the linphone sip library. Now there's hardly any notice-able delay when two people are talking to each other.
Related
I'm currently facing the task of programming an app (IOS and Android) where one feature will be a metronome for drummers.
I do not want to have multiple projects so i decided to use cordova. I stumbled upon many problems and solved some of them:
Can't use setInveral() or such for accurate timing
Can't use any other kind of "triggering" audio
The cordova NativeAudio plugin does also not do a good job in really accurate timing
So i came across the Web Audio API which is not supported by the Android Stock browser on most platforms so i found the crosswalk project which is ment to support the Web Audio API.
The good news is that my metronome test works great on a chrome browser on Desktop. It runs absolutely accurate in parallel with my hardware metronome. It also runs great if i open it with the current Android Chrome app.
It also runs on the android cordova application (Android 4.3.1, Galaxy Nexus) but there are two things that i couldn't figure out yet:
1.) When playing the click sound it sometimes sounds a bit laggy (like it has been triggered twice at a time but not always) and more important:
2.) The tempo seems to be constant but about 10-20 bpm slower compared to my desktop PC with the same settings.
It's kind of hard to put this into a fiddle but i hosted it myself under:
http://gonzales.capella.uberspace.de/sound/
You can find all the sources via the chrome debugger.
Any hint on why this is running slower on Android devices and how i can fix this will help a lot.
"Temp consistently slower" sounds like a sample rate conversion issue. At any rate, looping a generated audio file will work, but is kinda inefficient - I'd suggest a strategy more like the one I detailed in http://www.html5rocks.com/en/tutorials/audio/scheduling/.
BTW - the stock android browser is now Chrome, as of KitKat. That doesn't hit all Android out there, of course, but we are getting there.
I am an experienced Apple developer who is looking to develop for Android. I do not currently own any Android devices, so I am considering purchasing a B&N Nook HD for development purposes, which now runs Android. From the research I've done, it seems that the spectrum of Android devices is quite varied and disorganized compared to the Apple world (no offense intended). So, my question is, even though there are better (more expensive, too) devices to purchase (Nexus tablets), will a Nook HD suffice for beginning Android development? By the way, my intentions are to develop mostly tablet utilities with emphasis on networking and data manipulation. I'm not really interested in hardware-specific areas like graphics and sensory input (with the exception of the touchscreen, of course). Thank you for your advice.
In a general sense, yes. Your device will do just fine. However, a caveat is that you must take into consideration the flavor of android you are planning to target. e.g. Working on a Froyo flavor won't necessary guarantee it will run on the latest Jellybean and so on.
Hell, I started developing android almost 2 years ago (but stopped indefinitely) but it was only this year that I took it upon myself to get a PHYSICAL android device when I continued to develop my app. For no particular reason I just dropped by the local gadget mall and randomly picked the Samsung Tab 3. Yes, reviews are bad and it kernel panics a lot but these are trivial things for my specific use.
The one major problem I had? Dealing with REAL input from REAL data on a REAL device. My app worked sufficiently fine on the emulator. When it ran on the Tab it was breaking everywhere!
I built a very VOIP app for android phones. All i have is a text field that lets a user enter the username of the person they'd like to call. Then when they press call, it will wake up the recipients phone and play a ring tone. The recipient can answer or decline the call.
At the moment the app "almost" works fine on the following devices:
Galaxy Note 1 with OS 4.0.4
GS3 with OS 4.2.2 and 4.3
GS2 with OS 4.0.4
Nexus 4 with OS 4.2.2
Some minor issues I'm having are calls between some GS2 phones (GT-S7530M) to some GS3 phones, where the audio is extremely quiet. I'm not sure why this is, even though we maxed out the volume. Other times, there's plenty of crackling in the calls, or you miss out on people's sentences. We made sure the network speed was always at least 15mbps download and 1.5mbps upload.
Every other phone seems to work fine.
I am using linphone as the sip library for the phone. I am using asterisk as the telephone server. I am using GSM as the codec for the phone and for the asterisk server. I'm pretty sure I'm not doing anything "special" with my code. It's a simple app and I think any experienced Android developer will find my code pretty minimal and simple.
My question is, assuming I correct the issues for the targeted phones above, is it realistic for a single programmer to attempt to make this voip app work on 70% of modern android phones that are running OS 4.x+? Let's assume I want to be able to hit 70% target within a few weeks.
Some of you might think my question is too broad, so I want to make it clear that i'm just looking for a yes or no answer to whether it's realistic or not and the reason for your answer.
The reason I'm asking is because I had an earlier prototype, and I asked some strangers with other phones like Sony Xperia ZL, HTC One etc... and they seemed to have problems getting my app to work correctly. They experienced problems like the ring tone didn't work, or they couldn't receive a call (even though they successfully connected to my asterisk server), or the audio quality was extremely poor. This led me to do a bit more research on the popular problem known as Android Fragmentation. When I saw all the android phones out there, it scared me. Can I really reach 70% of modern android phones running OS 4.x all by myself in the next two weeks? Will this new version that I've created with bug fixes for Note 1, S3, S2 and Nexus 4 work perfectly on the other phones?
It's a very simple app
I long for the day when we can actually describe a custom VOIP app as being simple. It's 2013, and we cannot say that today with any degree of accuracy. IMHO, your app is rather complicated. It just so happens that most of the complicated bits are in a glob of open source code that you did not write (linphone) and a third-party server that you did not write (Asterisk).
It's a simple app and I think any experienced Android developer would find my code pretty minimal and simple
Pretty much all of the symptoms that you have described would either be part of linphone or part of Asterisk, from what I can tell. Your code may be simple, but your app is not.
is it realistic for a single programmer to attempt to make this voip app work on 70% of modern android phones that are running OS 4.x+?
If you remove linphone and Asterisk from the equation -- say, by rewriting your app to play a ringtone based upon an GCM user notification -- your objective seems reasonable.
However, since your app as presently constituted is almost completely linphone and Asterisk ("any experienced Android developer would find my code pretty minimal and simple"), your success is gated by how well linphone works on Android, and how well linphone-on-Android works when communicating with Asterisk.
Hence, the only people who will be able to answer that are those experienced with those technologies. You might try asking on some dedicated linphone and/or Asterisk resources. Or, you might ask fresh StackOverflow questions, with tags appropriate for those technologies, with more focus.
No. Some carriers inflict inanity: sip hostility or not awesome flavors of IPv4 to IPv6.
Currently I am also working on an Android VoIP client.
Actually there is no any difference between the different hardware and OS versions except this audio handling headache.
Unfortunately there are a lot of inconsistencies in the audio implementation by the different vendors. I would suggest you to have a look at some open source SIP softphone source code such as sipdroid, mizudroid and csipsimple. I was learnt a lot especially from sipdroid, although the code is not well commented. Be prepared to a lot of workaround handling each devices differently.
I've got an app out for Android that generates sound.
When the CPU is over worked, it doesn't run a tight enough loop and the result is snaps, crackles, and pops in the audio.
I was thinking that with newer devices, there would be less of this.
But it looks like on the tablets and newest phones, where I would expect better hardware and smoother audio, it usually seems to be worse than my old old Droid and Android 2.2.3.
I've got some more testing to do (I usually test this stuff in a Verizon or AT&T store as I can't afford all that hardware myself), but this seems to be the case so far.
What I'm wondering is there anything specific from Android 2 to Android 4 that could account for this?
For example a "governor" that limits how fast a Thread can run.
The loop is running in the run() of a subclass of Thread. It's created in an Activity (as opposed to a Service).
I would post the name and a link to the app (it's free) but I'm afraid that would probably be viewed as spam, or at least improper etiquette.
I am trying to do a demo on a android device, but the screen is too small so is kinda hard to do a demo let say in a meeting room with 12 people. Although I can pass the device around the table or just simple borrow or get more devices for the demo purposes.
I understand there are devies where you can buy special USB converter to do TV-out like in iPhone, and some specific devices on Android (e.g. Motorola Incredible?) But I have to demo on a specific device where it runs standard Android build.
I understand I can do it on Android emulator but the screen refresh rate is too slow, as it will send the wrong message to the audience that the app is slow. (Or there is a way to increase the screen refresh rate for emulator?) Furthermore the emulator doesn't support multitouch. (Or am I wrong?)
Not sure if anyone
You do not have many options.
You can use Droid#Screen, but the refresh rate on it is maybe 6fps. I am not aware of any other software projector that is faster.
You failed to mention the "specific device" that you are using, so I cannot comment on whether it has TV-out capability. The HTC DROID Incredible and the Samsung Galaxy S series support composite output -- I use the DROID Incredible for this purpose a fair bit. Most of the devices that have HDMI output only support it for certain built-in apps, such as the video player.
You can rent or purchase a device projector, like an ELMO. These are fairly expensive pieces of equipment purchased new, though I see a handful of used ones on eBay at interesting prices (though watch out -- many seem to lack the AC adapter).
If you can delay the demo several months, you may be able to use a Google TV.
And that's about it, AFAIK.
Or there is a way to increase the screen refresh rate for emulator?
Get a faster computer.
Furthermore the emulator doesn't support multitouch. (Or am I wrong?)
I am not aware of a way to simulate multitouch with an emulator, though I have not gone looking for a solution there.
If you have an Galaxy S3 Android mobile phone, you can use Mobizen. It's free and the screen refresh rate is relatively good. You can control you mobile phone from you computer using your mouse and your keyboard. It's working using USB, 3G or Wifi connection.
I have used this Android screencast tool: http://code.google.com/p/androidscreencast/ in past demos, but again the downside is the relatively slow refresh rate.
If you have a rooted device, you could try Droid VNC Server (it's on the market). The refresh rate isn't too bad, but I certainly wouldn't want to demo full motion video or an arcade game on it.
You could also get a webcam, rig it up with a tripod. Something like this. Downside is your hands will be in the way, maybe issues with lighting and/or focus. Upside is a decent refresh rate.