ubuntu-phone team mailing list archive

[Ricardo Salveti de Araujo <ricardo.salveti@xxxxxxxxxxxxx>]

On Tue, Feb 25, 2014 at 4:59 AM, David Henningsson
<david.henningsson@xxxxxxxxxxxxx> wrote:
> On 02/25/2014 04:21 AM, Ricardo Salveti de Araujo wrote:
>> On Mon, Feb 24, 2014 at 2:54 PM, Didier Roche <didrocks@xxxxxxxxxx> wrote:
>>> Hey,
>>>
>>> We took a big hit for multiple reasons since Friday. Our goal is to go back
>>> to a green baseline as soon as possible. The current image status isn't
>>> great[1], more details below.
>>>
>>> Consequently, we do *not* attribute any CI train silo nor landing which
>>> isn't targeted to get to a greener image or fix android 4.4 issue.
>>> Desktop-only impact landings can still land as usual. If you would like to
>>> help us getting greener faster, please see the "CALL TO ACTION" section
>>> below.
>>>
>>> In the meantime, we never had working image for flo and the emulator with
>>> 4.4, so those 2 were promoted on latest image (#206).
>>>
>>> First, we didn't have full image testing results since Friday (apart from
>>> latest one which was rerun, #206), due to issues Paul mentioned on the
>>> mailing list. This doesn't allow us to know if any regressions are coming
>>> from one of the 3 big landings: autopilot, unity8 and android 4.4.
>>> Fortunately, the autopilot and unity8 landings are small enough to hope they
>>> are not the root cause of any big issues. In addition to that, a lot of core
>>> apps have been updating and affect the global result as well.
>>>
>>> Let's sum up image by image:
>>> # 200:
>>> * this one mostly contains the autopilot change + what was discussed on
>>> Friday
>>>
>>> # 201:
>>> * mostly about new unity8 to isolate downloads in separate threads, card
>>> background support and a bigger sidestage threshold.
>>> * some core apps updates
>>>
>>> #202:
>>> * we got the click update UI back on the image
>>>
>>> -> we didn't get test results due to CI infrastructure issues.
>>>
>>> Then, we had the switch to the new android 4.4 kernel.
>>>
>>> #203:
>>> * First tentative version with the new android version, including hybris
>>> support
>>>
>>> # 204:
>>> * Minor changes, mostly some dropped dependencies on zeigeist
>>>
>>> # 205:
>>> * Some android configuration change for flo.
>>>
>>> # 206:
>>> * First real 4.4 version being able to be flash recovery and boot on your
>>> devices.
>>> * New music and terminal application. Music introduced a bug on first
>>> launch[2]. This wasn't in previous version of music-apps. Alan reverted it.
>>> We'll need upstream as well to ensure they write an integration test for
>>> that case.
>>>
>>> -> We didn't get until this morning any results on those image as the CI
>>> test infrastructure needed to be changed to take into account due to the new
>>> flashing image code being the only working for the 4.4 switch. 206 was rerun
>>> this morning and we see a lot of system-settle issues.
>>>
>>> It took a big part of the day to clear that out: idle definition changed in
>>> the kernel (it's based on all active CPU and not on all active + shutdown
>>> CPUs) as in the past. That's why we started to see pulseaudio and
>>> unity-system-compositor reporting higher CPU usage than they used to. We
>>> need to the CI team to accord to those new ways of reporting idle values.
>>
>> When trying to better understand why pulseaudio is constantly
>> consuming at least 1% of the cpu, I noticed that alsa ends up waking
>> pulseaudio quite frequently on mako, which might explain the cpu usage
>> (bug https://bugs.launchpad.net/ubuntu/+source/android/+bug/1284415).
>>
>> David, do you know if this is somehow the expected behavior? I though
>> pulseaudio would be mostly down all the time, but maybe this is not
>> the case when the device doesn't support
>> SNDRV_PCM_INFO_NO_PERIOD_WAKEUP.
>
> PulseAudio should only consume some CPU when playback/record is actually
> *running*. When there is no active stream, there is a five second
> timeout, then the connection to ALSA is closed. Closing the sound card
> device should lead to no interrupts, even on kernel level.

Right, that's what I thought as well.

> The jack detection through uevents is another source of wakeups, but
> it's not from ALSA. The reason that I commented it out was that the
> filter didn't work. I e, jack detection stopped working too. I didn't
> have time to root cause it at the time, which is why I left the
> filtering commented out. If you're sure it works now, then maybe it's
> something that was fixed on kernel level between 4.2 and 4.4 images?

I enabled the filter again and uploaded the change yesterday. I tested
with mako, maguro, grouper and flo, all worked fine (manta is not
working but not related with this change), all fine.

It could be that before we had that issue with android and udev, so I
hope to be better now.

>> Also looking at our boot log, I noticed that maliit-server always has
>> an open connection with pulse, which might not necessarily be what we
>> want. Bill, do you know if we can change maliit-server to only open
>> the connection with pulse if the user really wants sound on his
>> keyboard? At least pulse was not consuming any cpu after I disabled
>> maliit-server (saving battery).
>
> Just having a connection to PulseAudio should not cause CPU usage - only
> if you continuously stream audio through that connection.

Could be a bug with maliit-server, but I'd expect it to not be using
the connection at all unless you're typing something in the keyboard.

Cheers,
-- 
Ricardo Salveti de Araujo