Hi,
So I had a few more thoughts.
Let me start with a story :)
I use my N810 device for landline calls via SIP these days.
Every time I'm in a call, audio is very choppy and I can barely
understand the person I'm talking to -- my fix is to "ping -i
0.05" the device to disable its powersaving...
Now, why is audio choppy? I was blaming it on the wireless powersaving,
and disabling that clearly fixes it. But is the problem really just
there? I think it might also be the application -- its playback buffer
is smaller than the networking latency I am experiencing due to
wireless. I think I could probably tolerate an additional audio latency
of 150ms (my beacon interval being 102.4ms) or so, if audio wasn't
choppy. That means the application (telepathy sofiasip I guess) would
have to have 150ms or so playback buffer to make the playback smooth
with delay. [1]
Typical voip codecs will use between 8 and 64 Kibps net, adding IP
overhead and whatever you might be somewhere between 10 and 90 Kibps
which means you need to transfer at most 10KB per second -- which even
at a data rate of 1Mbps can be done, again with lots of overhead, in
much less than half the beacon interval (correct me if I'm wrong),
therefore your radio could still be sleeping quite a while!
Therefore, to properly do pm_qos, would the application request a 150ms
network latency in accordance with its playback buffer? Or this broken
application request 20ms and thereby disable PS completely?
johannes
[1] I don't quite see why this doesn't happen automatically, it seems it
must discard packets that don't fit into its idea of the stream timing
Attachment:
signature.asc
Description: This is a digitally signed message part
