long delay between loading and playing html5 audio

ASSIGNED
Assigned to

Status

()

Firefox for Android
Audio/Video
P5
normal
ASSIGNED
3 years ago
3 months ago

People

(Reporter: Marco Perez, Assigned: cpearce)

Tracking

(4 keywords)

Trunk
ARM
Android
html5, mobile, regression, testcase
Points:
---

Firefox Tracking Flags

(fennec+)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

3 years ago
Created attachment 8530634 [details]
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.
(Reporter)

Comment 1

3 years ago
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.

Updated

3 years ago
Assignee: nobody → snorp
Status: NEW → ASSIGNED
tracking-fennec: --- → ?
My changes only affect MP4, not OGG or MP3, so I don't think I'm the right assignee here.
Assignee: snorp → cpearce
(Reporter)

Comment 3

3 years ago
Created attachment 8531727 [details]
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.
Attachment #8530634 - Attachment is obsolete: true
(Reporter)

Comment 4

3 years ago
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.
tracking-fennec: ? → +
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.
Flags: needinfo?(bugmail)
Priority: -- → P5
(Reporter)

Comment 6

3 months ago
Created attachment 8910950 [details]
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...
Attachment #8531727 - Attachment is obsolete: true
(Reporter)

Comment 7

3 months ago
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...
Flags: needinfo?(bugmail)
You need to log in before you can comment on or make changes to this bug.