3s of lag seems a bit on the high side. Using cheap huawei's here in the lab, we typically see about 250-500ms of lag. Note that the cheap huawei's seem to have a 2KB hardware audio buffer, leading to (2KB / 16bit 8KHz ~=) 120ms of jitter that we can't do anything about. We'd like to implement some kind of echo canceler, but we haven't found anything that would be trivial to drop in. Our jitter buffer could probably use some improvements, I'm not going to say that it is in any way ideal. We're not managing network buffer bloat right now. When the wifi channel is busy, the rate that the kernel will send packets drops and can easily start to back up in the network stack. This can add a significant amount of latency. If packets don't arrive in time, the link state routing engine may be dropping the link, which would limit the number of outgoing packets, which would drop the latency, and the link would come back up again... We should be using RTT estimates to throttle our transmit rate to keep latency low, and feed into our link state calculations to work out when a link is really dead, or everything on that interface is just slow. But we haven't built anything like that yet. If we were limiting our transmit rate better, instead of sending lots of small UDP packets, we would try to aggregate more voice packets per UDP frame. Hopefully allowing the voice call to continue, just with higher jitter. Rhizome, and hence messaging, doesn't care as much if the network path is unstable. And it will just keep on trying until it gets there, making messaging *much* more reliable. We have some rough plans to implement a combination of push-to-talk / voicemail, using rhizome. And built into the messaging UI. But we don't have any concrete plans to start this work right now. And one day we may implement a form of network coding to reduce the number of packets required for bi-directional traffic over multiple hops. On Mon, Nov 18, 2013 at 4:21 PM, Miles wrote:

I've been testing with a pair of huawei 8150s using the stock gingerbread to connect to a 703n mesh extender. Wifi on the phones is pretty poor and my area is RF-noisy, so wifi works to about 2 blocks line of sight. I'm using about a 2 week old nightly build of the batphone app.

When the signal is strong, the phone works with about 3 seconds of audio delay and noticeable echo. When the wifi gets poor & drops to 2mb, voice cuts out entirely. text continues to work until wifi drops. Amusingly, voice calls drop at about the limits of my shouting voice.

Some of the problem is probably background /wind noise. I'd love a mute button on the batphone.

What should I do to improve voice experience , short of souping up the mesh extender? Do you usually use headsets? With PTT?

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe@googlegroups.com. To post to this group, send email to serval-project-developers@googlegroups.com. Visit this group at http://groups.google.com/group/serval-project-developers. For more options, visit https://groups.google.com/groups/opt_out.

-- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe@googlegroups.com. To post to this group, send email to serval-project-developers@googlegroups.com. Visit this group at http://groups.google.com/group/serval-project-developers. For more options, visit https://groups.google.com/groups/opt_out.