ubuntu-phone team mailing list archive

[David Barth <david.barth@xxxxxxxxxxxxx>]

On Wed, Mar 2, 2016 at 2:12 PM, Bill Filler <bill.filler@xxxxxxxxxxxxx>
wrote:

>
>
> > On Mar 2, 2016, at 4:54 AM, Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>
> wrote:
> >
> >> On Wed, Mar 2, 2016 at 10:37 AM, François DM <ledjazz@xxxxxxxxx> wrote:
> >> Dear all,
> >>
> >> I am having an annoying issue with my BQ Aquaris E5 HD.
> >>
> >> Basically whenever I listen to podcasts through the browser (
> soundcloud.com,
> >> franceculture.fr, etc.) I have to let the browser as the activated app.
> >>
> >> Otherwise, if I either lock the screen of the phone or switch to
> another app
> >> it stops rendering the audio (acts as a pause). This is a very annoying
> >> limitation.
> >>
> >> Is anyone having the same issue?
> >
> > This is a known (and long-standing) issue. Oxide (the web engine that
> > powers the browser app) isn’t fully hooked to media-hub (which handles
> > media queuing and playback on behalf of applications). So as soon as
> > it goes into the background, it is suspended, thus pausing the
> > playback.
> >
> > https://launchpad.net/bugs/1471786 has more information. Note that a
> > way around that issue could be to create webapps for those specific
> > websites, using the --enable-media-hub-audio command-line parameter.
>
> Is there a reason why this parameter is not the default for web browser
> app? Seems to me that it would be useful if this was turned on by default.
>

Hey Bill,

Let me explain why and bring some more context on the general integration
story. I hope this can help also understand where we come from and where we
plan to go.

The reason this option is not enabled by default is because this parameter
redirects *all* streams to media-hub, not just audio ones. It won't work
with webapps like youtube for example.

The Chromium API we had at our disposal provided no way to distinguish
between stream types. The main reason to delegate to media-hub is for its
ability to play in the background, which only makes sense for audio anyway.
For video, the embedded video support inside Oxide is already stable and
performant and we didn't want to risk potential regressions.

Longer term, and with the experience of integrating at just the audio
level, we feel that optimizations in the Oxide stack are a better way to go.

Not only to keep Oxide maintenance bearable (we need to stay aligned with
upstream for core features like this). But also because video and audio are
getting used and mixed intimately with the rest of the web elements (think
CSS transformations meet GL surfaces with video frames overlaid on top,
synchronized with an audio track). And that doesn't really fit the client
server, loosely coupled, media-hub model.

Going in this direction requires a low-latency, highly integrated
audio/video stack, which is best served by keeping the core Blink/Oxide
components together, and integrating with Ubuntu at the periphery.  With
hindisght, the simple audio integration, using a well-known API still
required a lot of open-heart surgery.

So we plan to keep this feature available as an opt-in, know-what-you-do
kind of feature. Until we are able to provide background audio support from
the Oxide stack itself.

David