This forum includes tips for maintaining the best audio quality possible with the Ooma System. If your Ooma system is having issues with dropped calls, static audio or echo, look here for assistance.
#87297 by Bill D
Sun Sep 18, 2011 6:07 pm
I'm been very pleased with my 3 Ooma Hubs over the last 2 years, other than the noticeable delay, which seems to be much more noticeable in 2011. (Perhaps because Ooma has more users). I've been tolerating this delay especially when talking to folks on cell phones.

Interestingly, lately I have been noticing that the delay is worse when I originate the call on Ooma. When the same cell phone that I called originates a call back to my same Ooma line, the delay during the entire call seems much less to both of us. (Perhaps one or both Ooma playout buffers are initialized differently depending on who originates the call or maybe the call routing is different).

To confirm my perception, I'm tempted to run a series of one-way delay measurements (with Audacity) between an Ooma Hub and my AT&T cell phone, but first, I thought I would post this and see if anyone else noticed this difference in delay or maybe even measured it.

Bill
#87305 by thunderbird
Mon Sep 19, 2011 5:04 am
It will be interesting to see if Ooma Telo delay becomes worse or improves, after Ooma Telo firmware update 49339 is received, because of the following fix.

Fix robotic voice that may occur under network congestion [11268].

I wonder if Ooma adjusted their Playout Buffers to make this correction?

For any one wanting to learn how to measure delay, view topic:
viewtopic.php?f=4&t=11377&hilit=Chronic+user
#87570 by Bill D
Sun Sep 25, 2011 3:45 pm
It does seem logical that robotic voice would be caused by an underrun of the playout buffer during network congestion. Setting the playout buffers larger would would give more time to avoid buffer underrun during network congestion, but at the expense of more delay.

I recall you said your delay problems were reduced by Ooma making a change unique to you. Maybe that change was reducing your playout buffer sizes (assuming Ooma can set them differently per user). I've never had voice quality problems but I have had delay problems so maybe my playout buffers are set high.

I did get inspired today to measure my delay a different way than before. I measured it "one-way" from my AT&T cell (iPhone4) to my Ooma Hub and vice-versa. I tested both directions twice - for calls originated from Ooma and calls originated from my cell. I used Audacity on my PC and put one phone on mute and speakerphone while I clicked the two phones together in front of the PC mic (then reversed which phone was on mute & speakerphone). Here's the results -
Code: Select all                                            Delay (one-way) measured
                                    from Ooma to Cell     from Cell to Ooma     Delay total (both ways)
Call originated from Ooma to Cell         400                 500                   900
Call originated from Cell to Ooma         350                 400                   750
As I suspected, the delay is worse when the call is originated from Ooma. The "total" shows the sum of the mouth-to-ear delay both ways, which is what the callers experience.

Concerning your comment about the new Telo SW rev - It would not affect me because I have Hubs.

Bill
#87573 by thunderbird
Sun Sep 25, 2011 4:57 pm
Bill I wonder what changing Codecs or star codes, does when testing for delay?

I know *99 works for a Hub.

I read one report that Ooma support told one Ooma user to use *82 (normally used for Send Caller ID), for another problem (For dialing 8xx numbers [and it worked]), but I don't know if *82 will work with a Hub?

Maybe another way can be found to trick "Ooma's Machinery" for a cure for chronic delay?
#87576 by Bill D
Sun Sep 25, 2011 6:14 pm
I repeated the same delay test for a call originated from Ooma preceded by *99 and *82. The delay was the same in each direction as my results shown above. Of course the incoming call test (originated from the cell) can't be done with *99 or *82 so those results would also be the same.

My best guess is that Ooma has fixed-lenght playout buffers in both directions which cause delay and protect against voice quality problems from buffer underrun. For some reason the buffer lenght is set smaller for incoming calls than for outgoing calls.

It would be nice to be able to try smaller buffers.

Bill
#87604 by Bill D
Mon Sep 26, 2011 8:25 am
jhphone's observations are interesting, but the *98 and *96 prefixes don't work on the Hub (I get a busy signal). The *99 and *82 prefixes work on the Hub (I get a second dial tone) but my delay measurements after using the *99 and *82 prefixes are the same as above.

Interestingly, my calls to 909-390-0003 from either of my two Hubs used to echo continuously and allow me to measure delay but now that number only gives me an echo for the first word I speak and is silent after that (same with calls from either of my two Hubs). However that echo number does echo continuously when I call it from my cell.

Bill
#87606 by thunderbird
Mon Sep 26, 2011 8:34 am
Bill D wrote:jhphone's observations are interesting, but the *98 and *96 prefixes don't work on the Hub (I get a busy signal). The *99 and *82 prefixes work on the Hub (I get a second dial tone) but my delay measurements after using the *99 and *82 prefixes are the same as above.

Interestingly, my calls to 909-390-0003 from either of my two Hubs used to echo continuously and allow me to measure delay but now that number only gives me an echo for the first word I speak and is silent after that (same with calls from either of my two Hubs). However that echo number does echo continuously when I call it from my cell.

Bill

I was a little excited to hear that jhphone said that delay is much less for him using the *9x prefexes. If he does the delay measurements and it's still less, it may be a break through for Ooma Telo users, if he's using an Ooma Telo.

Try calling the echo number using the *99 prefex and see if it helps?
#87609 by Bill D
Mon Sep 26, 2011 9:00 am
thunderbird wrote:Try calling the echo number using the *99 prefex and see if it helps?

Still no continuous echo on 909-390-0003 after using the *99 prefix or the *82 prefix.
#87611 by thunderbird
Mon Sep 26, 2011 9:17 am
Bill D wrote:
thunderbird wrote:Try calling the echo number using the *99 prefex and see if it helps?

Still no continuous echo on 909-390-0003 after using the *99 prefix or the *82 prefix.

I tested and has the same results as you.

I sent Bobby B. an E-mail requesting that he look into this problem.

Who is online

Users browsing this forum: No registered users and 8 guests