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.
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.
My changes only affect MP4, not OGG or MP3, so I don't think I'm the right assignee here.
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.
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.
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.
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...
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...