Skip to content

Static play API cuts off sounds in Chrome 67 #302

Closed

Description

@novwhisky

Issue Details

  • Version used: 1.0.0

  • Describe whats happening (Include any relevant console errors, a Gist is preferred for longer errors):

Note, this issue is not about Chrome's auto-play policy change, though it may relate to their rollback.

Using createjs.Sound.registerSound/createjs.Sound.play to play a sequence of MP3s will occasionally cause audio to cut off. Investigating further I found that there's a correlation between advancing sounds while Chrome's speaker icon is fading out. (i.e. the AudioContext disconnecting) The issue will not manifest if you click through very rapidly or conversely, wait for the previous source to fully disconnect.

  • OS & Browser version: macOS High Sierra 10.13.4 / Chrome 67.0.3396.79. Additional reports on Chrome/Windows

  • Do you know of any workarounds?

No, however attempting to console.log instance.sourceNode (even while DevTools are closed) causes the problem not to manifest, as though the additional function calls were enough to defer the event to a subsequent frame in the event loop.

I'm hoping switching to PreloadJS' LoadQueue might not be subject to the same issue and will try that next.

  • Provide any extra details that will help us fix your issue. Including a link to a [CodePen.io]

I've created an isolated test case at http://gallery.wi.tt/createjs-chrome-67/. Note that DevTools should not be open. This obviously makes it difficult to debug; In some cases (other than that mentioned above) I've found I can console.log certain data and then wait for the issue to reproduce before opening DevTools to see what's in the console.

Activity

  1. realjck commented on Jun 13, 2018

    @realjck

    I'm experiencing the same issue while using createjs.LoadQueue for sounds preload.

  2. novwhisky commented on Jun 13, 2018

    @novwhisky
    Author

    No-opping this if branch seems to prevent the issue from happening.

    p._cleanUpAudioNode = function(audioNode) {
    if(audioNode) {
    audioNode.stop(0);
    audioNode.disconnect(0);
    // necessary to prevent leak on iOS Safari 7-9. will throw in almost all other
    // browser implementations.
    if ( createjs.BrowserDetect.isIOS ) {
    try { audioNode.buffer = s._scratchBuffer; } catch(e) {}
    }
    audioNode = null;
    }
    return audioNode;
    };

    Of course, that'll prevent a lot of objects from GCing and eventually lead to a leak so I'm looking into the call stacks leading up to _cleanUpAudioNode()

  3. novwhisky commented on Jun 14, 2018

    @novwhisky
    Author

    Update: this appears to be a regression in Chrome that seems to be resolved in the latest beta (68.0.3440.25) https://bugs.chromium.org/p/chromium/issues/detail?id=849189

  4. Tiogshi commented on Jun 14, 2018

    @Tiogshi

    I'm using the Web Audio plugin for SoundJS, and using PreloadJS's load queue to preload assets coming up soon as well... and am noticing any current sound audibly cut off at the same moment that sound files finish preloading. However, the sounds which get muted are apparently still "running", as I am seeing the complete events for those sounds still get triggered.

    Hoping mainline 68 includes the fix.

  5. truonghongtrieu commented on Jul 31, 2018

    @truonghongtrieu

    I'm so glad that I found this discussion for the issue.

    I'm using Chrome 68 and everything works perfectly fine now!
    Release on July 25, 2018: https://developers.google.com/web/updates/2018/07/nic68
    Change list: https://chromium.googlesource.com/chromium/src/+/af747db680d72a467a49516384286fb31b2f681a

  6. realjck commented on Jul 31, 2018

    @realjck

    Since three years we develop e-learning webapps with CreateJS. Theses apps play audio dialogs all along (With a succession of 10-20 seconds length mp3).

    In our case this issue with Chrome 67 was a major one during the last two months. Our e-learning webapps were having sound cuts each minute and they became unusable on Chrome. I had to inform my clients to tell their students to switch to other browsers until Chromium pushes a new version.

    I'm glad that this have been fixed, and hope that the Chromium team understood how this bug have appeared to prevent a similar issue from happening again.

  7. lannymcnie commented on Jul 31, 2018

    @lannymcnie
    Member

    Glad Google sorted it out. Feel free to reopen if the problem persists past Chrome 67.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions