1157118 - Resuming playback of a .m4a file paused at the very end takes a long time

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[David Flanagan [:djf]]

This bug is a followup to a gecko issue I noticed while working on bug 1145758. 
In the FirefoxOS Music app, if I pause an m4a file, then use the scrubber to seek to the very end of the file, the app sets player.currentTime to Math.floor(player.duration).  So I now have an audio element playing an m4a song, paused less than one second from the end of the song.

If I now press play, it takes many seconds before playback resumes and I see the 'ended' event.  For a 2 minute song, it seemed to take 6 seconds. And for a 5 minute song, it seemed to take 12 seconds.  I was testing this on a FirefoxOS Flame device and my measurements are all very approximate. But it did seem to depend on the length of the song. And this issue did not seem to occur with .ogg or .mp3 files.  

See https://bugzilla.mozilla.org/show_bug.cgi?id=1145758#c32

I'm working around this gecko issue in bug 1145758, and don't have a test case to attach here, but I did want to at least get this filed so it doesn't get forgotten about.

Comment 1

[David Flanagan [:djf]]

I've only tried this on FirefoxOS. I don't know if it affects desktop. Actually, I don't even know if we can play .m4a files on desktop...

Comment 2

[Clément Lefèvre]

I did tests on .flac files too, just in case, as Firefox OS is now able to play them. Behavior was the same as for .mp3.

However, even if I could not get the very long time you described, it looks like songs are pausing like one or two seconds before starting to play the next one, either it naturally went to the end or you manually did it.

Comment 3

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.