ubuntu-phone team mailing list archive

[David Henningsson <david.henningsson@xxxxxxxxxxxxx>]

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.

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?

> 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.



-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic