Firefox hang in mozCurrentSampleOffset on jasmid site

RESOLVED FIXED

Status

Tech Evangelism Graveyard
English US
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: dougt, Unassigned)

Tracking

Details

(URL)

(Reporter)

Description

6 years ago
When loading http://jsspeccy.zxdemo.org/jasmid/ and clicking on one of the links, i see an unresponsive script dialogs a few seconds later.
Reproducible on Windows 7, with both the new audio backend and the old.  Also reproducible in Firefox 13.

Similar issue in Chrome: there it plays the entire tune, but the tab contents are completely unresponsive.

It looks like it used the Audio Data API on Firefox and Flash everywhere else, so that may explain the behavioural differences.

This might be a bug in the page, but I'll need to dig further to confirm.
So my profile shows that a lot of the time is under array_concat allocating new arrays.  In fact, it shows that 30% of total time is in the kernel in VM faults.

Those concat() calls are from http://jsspeccy.zxdemo.org/jasmid/audio.js line 30, which looks like this:

  'write': function(data) {
    if (buffer) {
      /* there's a backlog of stuff to write. Just append ours and return with an ETA */
      var dataPosition = writtenSampleCount + buffer.length;
      buffer = buffer.concat(data);
      return (dataPosition - audioElement.mozCurrentSampleOffset()) * 500 / sampleRate;
    }

Line 30 is the buffer.concat() line.

I see that code being called over and over again.  I never see the code in writeFromBuffer called, on the other hand so we never clear |buffer| and just keep buffering up data without ever writing it to the audio element.

Right now the |buffer| I'm looking at has length 5974338 and data is being added to it at about 2000-3000 entries per call.

Anyway, the reason that I see no calls to writeFromBuffer is that writeFromBuffer looks like this:

  function writeFromBuffer() {
    var written = audioElement.mozWriteAudio(buffer);
    writtenSampleCount += written;
    if (written < tail.length) {
      buffer = buffer.slice(written);
      setTimeout(writeFromBuffer, 20);
    } else {
      buffer = null;
    }
  }

There is no variable called "tail" around, so the first time it's called it will throw and exception and not reset the timer.  After that, |buffer| will remain nonnull, and there will be no more sound, just lots of memory consumption and a spinning CPU.

I assume that "tail.length" is meant to be "buffer.length"...

Doug, do you have a contact with these folks?
Oh, and all that code above is inside a "if (audioElement.mozSetup)", so it's only running in Firefox as comment 1 notes.
Code in https://github.com/gasman/jasmid/blob/master/audio.js looks pretty different from what's deployed on the site....
Ah, but the site matches the initial commit in that repo.  The code hasn't looked like that in the github repo since Feb 4, 2011....
Assignee: nobody → english-us
Component: Video/Audio → English US
Product: Core → Tech Evangelism
QA Contact: video.audio → english-us
Matt says he updated the page.  Can't test right now, because the pageload times out....
It's loading now, and works fine.  Thanks for investigating and contacting the author!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.