[Webkit-unassigned] [Bug 134925] New: iOS 8 prevents audio playback outside of user gesture even after Web Audio unmutes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=134925

           Summary: iOS 8 prevents audio playback outside of user gesture
                    even after Web Audio unmutes
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: iOS
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: ashley at scirra.com


Apparently by design, creating a new Audio() in javascript and playing it will cause no audio playback to occur unless the play() call is in a user input event like touchstart. This report is being made because this design makes no sense now that the Web Audio API has been introduced, and exists solely to impede legitimate use cases.

After a first touch, the Web Audio API becomes unmuted and can play audio at any time. However even after that Audio objects cannot play any sound unless in a user input event. The workaround is to AJAX the entire music track and play it with the Web Audio API. This has several drawbacks: the entire track must be downloaded and decoded entirely before playback can begin, as opposed to the HTML5 Audio element's ability to stream and start playback sooner; and the entire decompressed track must be held in memory, which is unacceptable on memory-constrained mobile devices. Therefore HTML5 audio is still necessary for playback of longer tracks such as music.

Once the Web Audio API is unmuted, continuing to limit Audio object playback serves no purpose. If the intent is to avoid surprising the user with sudden audio playback, the Web Audio API can do that anyway. If the intent is to avoid unexpectedly wasting bandwidth, the Web Audio API workaround will do that anyway, and then obnoxiously use loads of memory as well.

Legitimate use cases such as playing music in HTML5 games are still impeded by the limitation. For example if at some point after the Web Audio API unmutes the game switches to a "game over" screen which is dismissed on the first touch, it is impossible to play music on that screen, because the first touch is necessary to start music playback but also dismisses the screen. Even if a "dismiss" button is provided, the user is likely to press that immediately without providing another touch somewhere else to start music playback, so the game over screen music is still never heard.

iOS should treat Audio() objects the same way as the Web Audio API: after the first touch, playback is fully unmuted and can occur at any time. Continuing to limit Audio() playback while allowing arbitrary Web Audio playback serves no useful purpose and impedes legitimate use cases.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.