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
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.