web audio, pulse runs at 6% and screen will not blank on idle

[kevin gunn]

RTM krillin image #154

boot phone - go to Music scope, launch a song in grooveshark, let song start playing
application switch back to either Dash or some other application
Music will stop due to life cycle kicking in

Screen will not turn off
attach top - pulse running ~6%

if you open spread & kill the groove shark web page, the phone will then dim/screen blank on idle & you can see the pulse audio process eating 6% go away.

[kevin gunn (kgunn72)]

just confirmed this also happens with youtube videos as well.

[kevin gunn (kgunn72)]

also, when in this state striking the power key will dim/blank the screen.
however pulse continues running at 6%.
and if you turn the screen back on, it continues to refuse to dim at the end of the default timer.

[Pat McGowan (pat-mcgowan)]

@ricardo can you take a quick look

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ricardo Salveti (rsalveti)]

I was able to confirm that the audio stream will never really suspend on pulse when the apps get the stop request (from lifecycle). But pulseaudio has nothing to do with scream going off (dim), so opening a bug task against the system-compositor as that's the component responsible for dimming the screen.

The pulseaudio issue with the browser should be fixed once it starts using media-hub for audio playback, as we can control the playback state from the service itself.

Meanwhile will look if there is anything we can do on the pulse level.

[Ricardo Salveti (rsalveti)]

*screen :-)

[Ricardo Salveti (rsalveti)]

After checking a bit more on the pulse side, I believe that might indeed be just the expected behaviour and not a bug. I don't think pulse can simply stop/suspend the stream when the app gets SIGSTOP as there's no way to warn the app about the stream state.

One way to fix that would be adding a hook into the webrowser-app to stop/pause the multimedia streams when the app moves to the background (I believe there's a platform-api hook for that). One other fix would be the integration with media-hub, but afaik that's only for ota-1.

[David Henningsson (diwic)]

Good question; I'm not sure we have considered SIGSTOP at all.

If SIGSTOP just stops the process without doing any type of cleanup, and keeps all connections alive, that would be the same as the application being unresponsive.
PulseAudio will treat that as if the application does not supply data in time, and underrun, hoping that the application will come back within a few milliseconds or so.

For recording streams, PulseAudio will buffer up, hoping that the application will come back and read all buffered data. (It might be worth checking if this can cause an OOM situation after half an hour or so!)

I think it would make sense to introduce a timeout in both cases - 5-10 seconds or so until the application is considered "broken" by PulseAudio and do...at least something. :-)

[Andreas Pokorny (andreas-pokorny)]

The screen stays on and the timeout handling of u-s-c is deactivated since there is a keepDisplayOn request still active. As soon as the browser is closed the request is properly revoked...

[Andreas Pokorny (andreas-pokorny)]

Btw you can verify that by looking at the unity-system-compositor.log:

/var/log/lightdm/unity-system-compositor.log:
....
keepDisplayOn request id:0 requested by ":1.133"
remove_display_on_requestor ":1.133"
...

Above first line happens when video is started, and the second line when the video is paused. The second line is missing when the playback is stopped due to the lifecycle stop request, and only occurs when the webbrowser is stopped..

[kevin gunn (kgunn72)]

wrt application request to keepDisplayOn, i discussed with shell guys on irc and confirmed:
"unity8 not the intermediary (though IMO it shoud be) - so for now apps should be responsible and negate their request if they're put in background"

[kevin gunn (kgunn72)]

seems the culprit is webrowser-app,oxide making the request

[Olli Ries (ories)]

at this point we won't be blocking RTM for it, pls escalate once we know more

[Olli Ries (ories)]

contradicting myself after some more input from Kevin

impact on battery is bigger than first thought, hence tracking as topblocker for now

[Olivier Tilloy (osomon)]

> seems the culprit is webrowser-app,oxide making the request

I can confirm oxide issues the keepDisplayOn request.
Do child processes get stopped as well when an app is put in the background? If so, we’d need oxide to handle the stop signal and revoke the keepDisplayOn request (tentatively adding an oxide task).

[kevin gunn (kgunn72)]

yes, child processes do get stopped as well

[Bill Filler (bfiller)]

as a side note, I thought the Grooveshark webapp was whitelisted to allow music to keep playing in the background? Does grooveshark get launched in the Browser when invoked from the scope?

[kevin gunn (kgunn72)]

@bill - yes, grooveshark launches into the browser when you hit play from the scope. i'm not familiar with grooveshark and any attempt at whitelisting. afaik, it's only the music app today.

[David Barth (dbarth)]

@bill: nope, webapps don't get any extra permissions: they are constrained by the lifecycle and apparmor policy like any other application.

[Ricardo Salveti (rsalveti)]

On Nov 12, 2014 8:11 PM, "Bill Filler" <email address hidden> wrote:
>
> as a side note, I thought the Grooveshark webapp was whitelisted to
> allow music to keep playing in the background?

It's not white listed by the life cycle itself, but it keeps a request to
keep the display on (which affects the life cycle only when foreground).

In the end the result is similar and can block the phone when suspending
(only that when on background it should release everything).

[Ricardo Salveti (rsalveti)]

On Nov 12, 2014 12:25 PM, "Olivier Tilloy" <email address hidden>
wrote:
>
> > seems the culprit is webrowser-app,oxide making the request
>
> I can confirm oxide issues the keepDisplayOn request.
> Do child processes get stopped as well when an app is put in the
background? If so, we’d need oxide to handle the stop signal and revoke the
keepDisplayOn request (tentatively adding an oxide task).

Do you think it could also pause the playback when revoking the
keepDisplayOn request? That would also help releasing the resources from
pulse.

[Olivier Tilloy (osomon)]

> Do you think it could also pause the playback when revoking the
> keepDisplayOn request? That would also help releasing the resources
> from pulse.

Actually, pausing the playback would release the keepDisplayOn request, so what we need is oxide to pause playback when stopped.

[Olivier Tilloy (osomon)]

Marking invalid for webbrowser-app as the work needs to happen in oxide itself.

[Olivier Tilloy (osomon)]

> Actually, pausing the playback would release the keepDisplayOn
> request, so what we need is oxide to pause playback when stopped.

After a bit of investigation, it turns out that there is no API in chromium to request pausing all currently playing media. Even if there was one, the SIGSTOP signal can’t be caught anyway.

Quoting chriscoulson: "Requiring apps to pause their own media is broken by design anyway. what should happen is the other session bits responsible for handling it (eg, pulseaudio) should be told when a client has been stopped. Doing it any other way is quite fragile - even if an application doesn't ignore it, it could be busy with something else when it goes in to the background, so it doesn't have time to stop its media before the process is stopped"

So what we really need is for pulseaudio and unity to be notified when an app is stopped, and release the corresponding resources (audio stream, screen dim lock), to restore them when the app is continued.

[Olivier Tilloy (osomon)]

(note that the above will probably be addressed when we fully switch to using media-hub in oxide, as I expect it will handle screen dim prevention too)

[Ricardo Salveti (rsalveti)]

Remember we don't want to handle things when getting a SIGSTOP, we want to do that when lifecycle tells us that the app is going to be suspended (which happens before SIGSTOP).

Pulseaudio could be responsible for releasing his own resources, but that is not going to help much on the original bug here (about screen staying on). It's fine to expect the app to react and pause the stream when going to the background, I don't see how that could be a design issue.

[Ricardo Mendoza (ricmm)]

Building up salveti's comment, the right way to do this is to make use of the application active status in webbrowser-app and use that to stop the media playback, or release the screen on request.

The way I understand the issue right now is that there is no obvious comms path for webbrowser to ask oxide to release the display request? Basically the only process that is told that its being put to the background is the actual application (webbrowser-app), whatever its helper processes do on this information is up to the app; in this case it needs to implement this signal to oxide so that it releases the resource.

NB: Qt.application.active for app state, or its C++ implementation taking the event form the QApplication event loop.

[Ricardo Mendoza (ricmm)]

We've just had a call to discuss this, the outcome is the following:

Make use of com.canonical.Unity.WindowStack API (from QtMir) to implement a state tracker in Oxide, so that it is aware when its webbrowser-app process has gone out of focus, in order to release the screen request and let the system suspend. In the same way, Oxide must retake the request once the process comes back into focus, so that playback may continue.

[Bill Filler (bfiller)]

>>Make use of com.canonical.Unity.WindowStack API (from QtMir) to implement a state tracker in Oxide,
>>so that it is aware when its webbrowser-app process has gone out of focus,

Will need to do the same thing for webapp-container process as well?

[Olivier Tilloy (osomon)]

> Will need to do the same thing for webapp-container process as well?

No, webapp-container is running confined, and thus isn’t allowed to request preventing screen dimming.

[Launchpad Janitor (janitor)]

This bug was fixed in the package oxide-qt - 1.3.4-0ubuntu0.14.10.1

---------------
oxide-qt (1.3.4-0ubuntu0.14.10.1) utopic-security; urgency=medium

  * Update to v1.3.4
    - see USN-2410-1
    - Bump Chromium rev to 39.0.2171.62
    - Fix LP: #1260016 - Add support for application provided protocol
      handlers
    - Fix LP: #1301681 - Scroll the focused editable node in to view after
      a resize
    - Fix LP: #1337506 - Runtime abort with
      FATAL:texture_manager.cc(76)] Check failed: texture_count_ == 0u (1 vs. 0).
      Ensure that we keep the browser compositor GL context and associated
      resources alive as long as the Qt scenegraph holds the frontbuffer
    - Fix LP: #1377755 - Keyboard disappears when switching between text fields
    - Fix LP: #1290821 - WebView.loading is not false when receiving a LoadEvent
      with type == TypeStopped, so properties bound to this never receive an
      update. As "loading" and the main-frame document load events are delivered
      separately from blink, split this in to 2 signals
    - Fix LP: #1354382 - White line at bottom of viewport - fix rounding errors
      when calculating the view size in DIP which results in the view
      underflowing by a pixel in one axis and overflowing by a pixel in the
      other axis
    - Fix LP: #1221996 - Allow user scripts to be injected in to the main world
    - Expose redirect events to WebContextDelegateWorker
    - Fix LP: #1384460 - Delegate unhandled URL schemes to the system
    - Fix LP: #1386468 - Stop leaking V8 contexts
    - Fix LP: #1375900 - GMail crashes when composing a message
    - Fix LP: #1391230 - Release the screen dim lock when the application
      becomes inactive

  [ Chris Coulson <email address hidden> ]
  * Add liboxideqtquick0 package
  * Refresh debian/patches/gross-hack-for-dual-ffmpeg-build.patch
  * Add libcups2-dev and libexif-dev build-deps, as the chromedriver build
    seems to pull them in. This is a temporary measure until we can figure
    out why

  [ Alexandre Abreu <email address hidden> ]
  * Add chromedriver to the packaging branch
 -- Chris Coulson <email address hidden> Mon, 17 Nov 2014 11:16:34 +0000

[Ricardo Salveti (rsalveti)]

Just tested 166 and the browser was still holding up a screen lock, making it unable to suspend.

Try playing something with grooveshark and then moving back to the home scopes, the screen will still be on (even after 60s).

current build number: 166
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2014-11-20 00:35:58
version version: 166
version ubuntu: 20141119
version device: 20141119-db417fa
version custom: 20141119-442-21-160

[Ricardo Salveti (rsalveti)]

Not able to reproduce this every time, so it seems it was partially fixed.

[Ricardo Salveti (rsalveti)]

It seems it always happen at the first time you play something after a reboot. At the second time I tried, it worked fine.

[Olivier Tilloy (osomon)]

I found the culprit: the very first call to com.canonical.Unity.Screen.keepDisplayOn returns a cookie with value 0, whereas oxide always assumes it will be > 0.

[Olivier Tilloy (osomon)]

Fixed in oxide trunk and in the 1.3 branch, will be part of the next point release, 1.3.5.

[Launchpad Janitor (janitor)]

This bug was fixed in the package oxide-qt - 1.3.5-0ubuntu0.14.10.1~rtm

---------------
oxide-qt (1.3.5-0ubuntu0.14.10.1~rtm) utopic; urgency=medium

  * Update to v1.3.5
    - Bump Chromium rev to 39.0.2171.65
    - Really fix LP: #1391230 - Release the screen dim lock when the
      application becomes inactive
 -- Chris Coulson <email address hidden> Thu, 20 Nov 2014 11:01:29 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package pulseaudio - 1:4.0-0ubuntu22rtm1

---------------
pulseaudio (1:4.0-0ubuntu22rtm1) 14.09; urgency=medium

  * debian/patches/0300-corking-a-sink-input-stream-when-stalled.patch:
    - Identifying and corking a sink-input stream when it gets stalled
      (LP: #1391230)
 -- Ricardo Salveti de Araujo <email address hidden> Mon, 24 Nov 2014 11:17:42 -0200

[Nara Huang (narahuang)]

I could also reproduce this issue with Mako, using Vivid r88
Pulseaudio version: 1:4.0-0ubuntu23

The pulseaudio is still holding 6% CPU usage even switch to other application.

[Launchpad Janitor (janitor)]

This bug was fixed in the package pulseaudio - 1:6.0-0ubuntu5

---------------
pulseaudio (1:6.0-0ubuntu5) vivid; urgency=medium

  * debian/patches/0211-corking-a-sink-input-stream-when-stalled.patch:
    - Identifying and corking a sink-input stream when it gets stalled
      (LP: #1391230)
 -- Ricardo Salveti de Araujo <email address hidden> Tue, 07 Apr 2015 00:40:56 -0300