1106392 - long delay between loading and playing html5 audio

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: Audio/Video, defect, P5)

Description

[Marco Perez [:mpk]]

Attachment: simple testcase for vorbis/mp3 with on-screen event logging

The delay between loading an audio stream and playing it has jumped significantly lately.

Steps to reproduce:
 - bug occurs on mobile Firefox only (desktop versions work fine)
 - only Nightly builds from 2014-11-14 or later are affected
   (Aurora may get the bug shortly, though)

Regression window is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=688f821edcd4&tochange=7f0d92595432

I'm not sure if this is a generic problem related to my particular handset and/or OS. I wouldn't be astonished if it occurred on SGS2s (GT-I9100) and SGS3s (GT-I9300) running CyanogenMod only. I was able to reproduce it on a Samsung Galaxy S2 (GT-I9100) running CyanogenMod 11.0 (Android 4.4.4) with default settings.

When using the attached testcase on older mobile builds or desktop builds, playing events occur with a delay of about:
 - Ogg Vorbis (32kbps):   2.5s - 3.0s
 - Ogg Vorbis (160kbps);  0.5s - 1.0s
 - MP3 (128kbps):         1.5s

With newer Nightly builds the delay rises dramatically:
 - Ogg Vorbis (32kbps):   11s
 - Ogg Vorbis (160kbps):  46s
 - MP3 (128kbps):         unknown (might take "forever")

This may well be the result of a wanted change, but even so the delays are extremely high.

Comment 1

[Marco Perez [:mpk]]

Oops, there was a mistake in the figures for the new delays. Vorbis 32kbps is the slower one:
 - Ogg Vorbis (32kbps):   46s
 - Ogg Vorbis (160kbps):  11s
 - MP3 (128kbps):         unknown (might take "forever")

And the steps to reproduce are actually missing the main step: connecting to a stream
This is easily accomplished using the attached testcase.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

My changes only affect MP4, not OGG or MP3, so I don't think I'm the right assignee here.

Comment 3

[Marco Perez [:mpk]]

Attachment: testcase v2, with some options added

Files seem to be much less affected than streams. MP3 files take just a tiny bit longer (maybe 20%). And Vorbis files about 400%. At least that's what I got with the OpenBSD 3.0 release song over a broadband connection.

It gets really interesting when switching to GSM (e.g. <100kbps). While the old times were roughly:
 - Ogg Vorbis (file): 2 - 4s
 - MP3 (file):        0.1 - 0.3s

With the bug they're:
 - Ogg Vorbis (file): 21 - 22s
 - MP3 (file):        0.1 - 0.3s

So it seems we weren't doing that great for Ogg Vorbis before either. Opus might be similar to Vorbis. Haven't had a chance to test it yet.

Comment 4

[Marco Perez [:mpk]]

Enabling the new "Allow autoplay" setting makes the problem go away.

That's kinda strange. Shouldn't disabling it suppress real autoplay
altogether but leave user-initiated playback virtually untouched?

What happens here seems to be something in between.

Comment 5

[John Lin [:jhlin][:jolin]]

Hi Marco, could you please help test with the latest nightly(57)? I tried your tests in the attachment (files only, stream links seem broken now) on Nexus 5/Android 4.4.2 and heard them playing in a short time. But the numbers don't make sense to me:

Ogg Vorbis (file)
3xxxxx ms

MP3 (file)
3xxxxx ms

Thanks a lot.

Comment 6

[Marco Perez [:mpk]]

Attachment: testcase v3, cleaned up and unbitrotted

Ok, seems like some of the online radio streams were indeed dead.
In addition, the spec for Event.timeStamp changed quite a bit.
This reworked testcase should make the testing a lot easier.
Hm, let's see...

Comment 7

[Marco Perez [:mpk]]

A current nightly build (same hardware but newer Android) gives better results:
The playing starts with a delay between 2 and 3 seconds (AAC/MP3/OGG streams).

The original regression is solved, even though the delays might be a bit worse.
Unfortunately, I haven't found any streams comparable to the original ones yet.

I wonder whether it would be possible to attain sub-second delays like we used
to have for mp3 streams...

Comment 8

[Firefox Bug Husbandry Bot]

Re-triaging per https://bugzilla.mozilla.org/show_bug.cgi?id=1473195

Needinfo :susheel if you think this bug should be re-triaged.

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

I tested this in GeckoView_example on the MotoG5, and we start playback very fast in that, usually faster than Chrome on the same device. So I'm going to close this bug under the assumption that it'll be fixed when Fenix ships based on GeckoView.