On Friday 10 December 2010 00:53:19 ext Marcel Holtmann, you wrote:
> > this is not really true. We can not wakeup ofonod every
> > You might wanna start running powertop.
Yes we can. PulseAudio is going to be waking up the CPU 10 times per seconds
> uhm, but I'm not claiming that. I was just stating that
> the timers to e.g. pulseaudio in this case won't save much if
> anything (the CPU will be woken up anyways, and the cost between
> scheduling ofonod or a thread from PA, has really no difference
> to overall consumption.. the CPU is woken up anyways and roughly
> the same code to handle the timer is run).
> So whether this code is in oFono or elsewhere, does not matter
> much (to overall power consumption). The main question is of course
> how often the counters are synced.
actually it does matter since you have no extra context switch and in
addition you not accidentally wake up PA and then ofonod. You have one
centralized wakeup of one thread.
No! The one extra context switch is negligible compared to the several few
system calls that updating the call counter requires. And as Kai already said,
the CPU will wake up anyway.
The real power consumption difference lies in the I/O, which would not happen
if it weren't for fault-tolerant call counters. In that respect, which process
writes, PulseAudio, oFono, or something else, is irrelevant.
Of course this should be smart and done along with the PA audio
processing and not async to that one.
No. PulseAudio has no business with the call counters. It might not know that
it is a call. And even if it did know, it might not know whether the call is
ringing or connected.
oFono on the other hand has the informations. Also, if we gave up on fault
tolerance to save power, oFono would be the logical place to provide call
counters (through D-Bus). So it only makes sense that oFono does this - if
And then, it's our nor your decision to make how often (if at all) the call
counters need to be flushed to the memory card. That's a matter for the
vendor's legal & liability departement. So it really just needs to be
configurable, including the ability to disable the feature altogether if it is
If we consider that the only sensible thing is to track the actual
talking time, then PA becomes a nice choice for this.
I don't think so.
This doesn't mean that you should be implementing it, but I am
maintaining that this would be a pretty damn smart way of solving this
> Personally I think the every-10sec interval is too short.
> It's also highly system specific when wakeups start to get
> too costly, so picking up one value seems difficult.
My take here is that a granularity of 1 minute is enough.
There are definitely call fares with sub-minute granularity. The minute is
Doing this every 10 seconds and displaying it on a per second level
sounds insane to me.
So I made a lengthy call to my mum this morning, using a desk phone. And it
was showing minute:second, not just minutes. I have never seen a phone that
does not show seconds and it would look pretty dumb to me.
But of course, that's a matter for UI designers, not for middleware oFono
software engineers anyway.
Nokia Devices R&D, Maemo Software, Helsinki