|
2011-06-06
, 06:08
|
Posts: 477 |
Thanked: 118 times |
Joined on Dec 2005
@ Munich, Germany
|
#72
|
|
2011-06-08
, 21:40
|
Posts: 356 |
Thanked: 123 times |
Joined on Dec 2008
|
#73
|
I have been trying to get this to work, but with the newest power kernel I am having some issues (it doesn't seem to be performing the dbus actions. Did something change in PR1.3?)
I removed this dbus script, and used "kernel-config show" to monitor the cpu settings. I noticed that the min. frequency is set to 600 when the call starts ringing (outgoing), but as soon as the actual call starts, the minimum frequency drops back to 125.
It seems like something is wrong here. Maemo looks like it is trying to set the cpu to 600mhz during calls, but it gets reverted back to the normal settings right when the call starts. Can someone else make a call, monitor the minimum frequency during the call, and see if they get the same issue?
|
2011-06-09
, 00:43
|
Posts: 4,030 |
Thanked: 1,633 times |
Joined on Jul 2007
@ nd usa
|
#74
|
|
2011-06-09
, 05:32
|
Posts: 306 |
Thanked: 106 times |
Joined on Feb 2010
|
#75
|
|
2011-06-09
, 09:15
|
Posts: 79 |
Thanked: 37 times |
Joined on May 2010
@ Melbourne Australia
|
#76
|
|
2011-06-09
, 10:33
|
Posts: 15 |
Thanked: 3 times |
Joined on Apr 2011
@ The Netherlands
|
#77
|
|
2011-06-09
, 14:50
|
Posts: 93 |
Thanked: 13 times |
Joined on Nov 2010
|
#78
|
I had some choppy audio problems , but I solved it very easily. I'm running the default updated kernel without any adaptation what so ever. I guess this proves that SIP/VOIP is able to work on the N900 under Maemo 5 PR 1.3 without any tinkering on the device.
So I like to share my experience, perhaps it will help one of you guys.
As far as I experienced it, the choppy audio is a bandwidth problem, not a software/hardware problem. It is not the N900's fault
In my case my N900 connects to Skype, GTalk and two SIP servers (one public, one private), and makes calls without any problems.
The two things I did to achieve this were:
1) Allow only the use of iLBC by both private, and the public SIP server. Because this codec uses so little bandwidth it is small enough to use on mobile (3G) networks (In my case TMobile 3G network), after this the choppiness while using a mobile connection was gone.
2) Setup the quality of service (QoS) of your network to give SIP/VOIP traffic maximum priority. I gave traffic on ports used by SIP/Skype/GTalk maximum priority over everything else. In my case I did the configuration in a WRT54GL router running Tomato 1.27, it has a really neat and functional QoS menu. I encountered a couple of routers with really limited QoS functionality, which had a negative effect on the quality of the SIP/Skype/GTalk calls, replacing them with something running Tomato made a real difference.
Sometimes I have a choppy connection, but that is always a remote problem, the person calling me is behind a router with a really lousy QoS setup or is on a 2G network.
I don't use video calling a lot, but it also seems to work with these settings, I'm not sure about the 3G connection though. It all depends on the amount of bandwidth given to you by your operator. The mobile connection I use is a TMobile connection, it's quite a lean connection, but it is cheap, €2,50 p/m. I guess paying more money would give me more bandwidth, but when using the iLBC it's more than enough, I don't know how much bandwidth the video-stream requires, I'm sure it needs more bandwidth than audio only.
The Following User Says Thank You to rosh For This Useful Post: | ||
|
2011-06-10
, 01:40
|
Posts: 79 |
Thanked: 37 times |
Joined on May 2010
@ Melbourne Australia
|
#79
|
|
2011-06-12
, 18:52
|
Posts: 306 |
Thanked: 106 times |
Joined on Feb 2010
|
#80
|
It's hard to tell if it's better yet, so I will report back in a few days.
If people are interested, I can post a more complete set of instructions.
I removed this dbus script, and used "kernel-config show" to monitor the cpu settings. I noticed that the min. frequency is set to 600 when the call starts ringing (outgoing), but as soon as the actual call starts, the minimum frequency drops back to 125.
It seems like something is wrong here. Maemo looks like it is trying to set the cpu to 600mhz during calls, but it gets reverted back to the normal settings right when the call starts. Can someone else make a call, monitor the minimum frequency during the call, and see if they get the same issue?